[Laszlo-user] [Laszlo-dev] Need to be able to override resource declarations in OpenLaszlo without warnings.
P T Withington
ptw at openlaszlo.org
Thu Aug 30 05:29:00 PDT 2007
Hm. I think I would rather fix 3477 than have this replaceable
resource approach. It seems more CSS/standardy. Unless there is
some requirement that we have these resource declarations.
If we are going to support the replaceable bit, we might want to use
the terms that are coming our way from Javascript 2, which is to
label attributes that can change `dynamic` and to label an attribute
that is intended to replace another dynamic attribute `override`.
Thus the base library designer declares their intent to permit
overriding, and the designer extending the base library declares
their intent to override.
On 2007-08-30, at 00:03 EDT, Elliot Winard wrote:
> We can't specify the long name in CSS right now. I don't know
> enough about the implementation to know exactly why.
>
> http://www.openlaszlo.org/jira/browse/LPP-3477
>
> P T Withington wrote:
>> Remind me why we have resources? They just seem to serve to give
>> you a short name for a longer name. Why can't we skip resources
>> altogether and specify the long name directly in CSS? Is this due
>> to some underlying limitation in the SWF runtime?
>>
>> On 2007-08-29, at 12:56 EDT, Elliot Winard wrote:
>>
>>> I like this proposal.
>>>
>>> That means that there are now two ways to "skin" an app -
>>> * using CSS
>>> * overwriting named resources
>>>
>>> Using overwritten resources will make compile-time skinning more
>>> palatable than the 2-step CSS option we currently have. It'd
>>> still be nice to be able to support assigning of resource file-
>>> names in CSS. (LPP-3477 <http://www.openlaszlo.org/jira/browse/
>>> LPP-3477>)
>>> -e
>>>
>>> Bret Simister wrote:
>>>> I prefer putting the responsibility on the developer creating
>>>> the library, rather than on the developer using it.
>>>>
>>>> Hence,
>>>>
>>>> <!-- mylibrary.lzx -->
>>>> <library>
>>>> <resource name="logo" src="logo.png" replaceable="true" />
>>>> </library>
>>>>
>>>> would allow a developer using the library to write the following
>>>>
>>>> <canvas>
>>>> <inlcude href="mylibrary.lzx" />
>>>> <resource name="logo" src="logo2.png" />
>>>> </canvas>
>>>>
>>>> and see no warnings upon compile. This seems the cleanest
>>>> approach to me.
>>>> It lets the library developer be explicit about which resources
>>>> were designed
>>>> to be replaced.
>>>>
>>>> I am also OK with Henry's suggestion about using a compiler
>>>> flag to show warnings
>>>> when you need to check for resource conflicts. The nice thing
>>>> about that approach is that
>>>> it has minimal impact upon the language.
>>>>
>>>> -Bret
>>>>
>>>>
>>>>
>>>> On Wed, Aug 29, 2007 at 8:03 AM, Elliot Winard wrote:
>>>>
>>>>> I can see something like that working -
>>>>> <resource name="logo" src="blah.png" force="true" />
>>>>>
>>>>> If the force attribute is present, it overwrites other
>>>>> declarations of logo and does *not* emit a warning.
>>>>> The force attribute could mean both "replaceable" and "suppress
>>>>> warning".
>>>>> The warning could suggest that the force attribute be used if
>>>>> the user intends to overwrite in case of conflict.
>>>>>
>>>>>
>>>>> Resources in libraries could define the force
>>>>> <library>
>>>>> <resource name="logo" src="logo.png" force="true" />
>>>>> </library>
>>>>>
>>>>> <library>
>>>>> <resource name="logo" src="logo2.png" force="true" />
>>>>> </library>
>>>>>
>>>>> Hrm. Come to think of it, that feels wrong. Would it be too
>>>>> much of a change if there are two new attributes for resource -
>>>>> force and replaceable?
>>>>> @force would be tell the compiler not to emit a warning if this
>>>>> resource overwrites another.
>>>>> @replaceable would tell the compiler not to emit a warning if
>>>>> this resource is overwritten
>>>>>
>>>>> If these two attributes aren't present the current behavior
>>>>> remains.
>>>>> So resources in Webtop libraries would look like this -
>>>>> <library>
>>>>> <resource name="logo" src="logo.png" replaceable="true" />
>>>>> </library>
>>>>>
>>>>> -e
>>>>>
>>>>> Sarah Allen wrote:
>>>>>> That is exactly the dilemma. The tension is between a the
>>>>>> frustration of an accidental override and the frustration if
>>>>>> you want to set up your library to allow customizing a
>>>>>> resource, where you have to provide a resource file and
>>>>>> library separately and then the user of the library needs to
>>>>>> create a new resource file and include all your resources
>>>>>> except the logo and include the logo.
>>>>>>
>>>>>> I suppose there could be some kind of flag that says that I
>>>>>> meant to override this resource, like:
>>>>>> <resource name="logo" src="logo.png" replace="true"/>
>>>>>>
>>>>>> I don't know if that would complicate the implementation or
>>>>>> the language folk would consider it weird, but as a user of
>>>>>> the language it would work for me.
>>>>>>
>>>>>> Sarah
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 29, 2007 at 5:01 AM, Elliot Winard wrote:
>>>>>>
>>>>>>
>>>>>> I don't know about removing the platform warnings.
>>>>>>
>>>>>> If I include two libraries that have resources with
>>>>>> conflicting names, I want to know about it. For example - I
>>>>>> might include multiple libraries , each defining a 'logo'
>>>>>> resource and expecting the logo to be sized a certain way -
>>>>>> <include "mailwindow" />
>>>>>> <include "stockwindow" />
>>>>>>
>>>>>> I want the compiler to tell me that the stockwindow's logo is
>>>>>> overwriting the mailwindow's logo. Warnings are informative,
>>>>>> non-fatal and should be used to provide this kind of information.
>>>>>> This proposal skirts CSS altogether. If this gets implemented
>>>>>> as proposed then the display of warnings should be
>>>>>> configurable at compile-time. I think it would be confusing
>>>>>> to users if resources (or classes or instances) get clobbered
>>>>>> without any warning.
>>>>>> -e
>>>>>>
>>>>>> Sarah Allen wrote:
>>>>>>> I think this is an excellent proposal. cc'ing laszlo-user
>>>>>>> to see if
>>>>>>> other folks developing in LZX have strong feelings about
>>>>>>> this ...
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 28, 2007 at 3:12 PM, Bret Simister wrote:
>>>>>>>
>>>>>>>
>>>>>>> Currently, in the OpenLaszlo platform, it was decided that
>>>>>>> declaring a
>>>>>>> resource twice within an LZX app
>>>>>>> causes a server warning. This was intended to help developers
>>>>>>> just in
>>>>>>> case they accidentally overrode a
>>>>>>> resource that had already been declared in another library.
>>>>>>>
>>>>>>>
>>>>>>> <!-- the following code produces a warning, but still
>>>>>>> compiles -->
>>>>>>> <canvas>
>>>>>>> <resource name="logo" src="logo.gif" />
>>>>>>> <resource name="logo" src="logo2.gif" />
>>>>>>>
>>>>>>> <!-- view appears with logo2.gif -->
>>>>>>> <view resource="logo" />
>>>>>>> </canvas>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> At this time, I would suggest that the platform remove these
>>>>>>> warnings and have
>>>>>>> the last resource declaration override all other previous
>>>>>>> declarations.
>>>>>>>
>>>>>>>
>>>>>>> Here is why...
>>>>>>>
>>>>>>>
>>>>>>> OpenLaszlo now has a CSS implementation. It gives developers an
>>>>>>> elegant method
>>>>>>> of skinning their applications. This works, currently, by first
>>>>>>> declaring a resource
>>>>>>>
>>>>>>>
>>>>>>> <resource name="someimage_rsc" src="somepath/someimage.jpg" />
>>>>>>>
>>>>>>>
>>>>>>> and then referring to that resource in a CSS selector
>>>>>>>
>>>>>>>
>>>>>>> view[name="someview"] {
>>>>>>> resource: someimage_rsc;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If a developer builds a library ....
>>>>>>>
>>>>>>>
>>>>>>> myCustomLibrary ( folder )
>>>>>>> library.lzx
>>>>>>> myresources.lzx ( contains many resource definitions
>>>>>>> including
>>>>>>> 'lowerRightCorner_rsc' )
>>>>>>> mystyles.css ( contains many selectors including one
>>>>>>> that
>>>>>>> references 'lowerRightCorner_rsc' )
>>>>>>> ... ( other class and source image files )
>>>>>>>
>>>>>>>
>>>>>>> where library.lzx includes both myresources.lzx and
>>>>>>> mystyles.css
>>>>>>> Then library can be used with a simple inclusion in the
>>>>>>> main app.
>>>>>>>
>>>>>>>
>>>>>>> <canvas>
>>>>>>>
>>>>>>>
>>>>>>> <include name="myCustomLibrary" />
>>>>>>>
>>>>>>>
>>>>>>> <!-- instance of a class from myCustomLibrary -->
>>>>>>> <mycustomclass />
>>>>>>>
>>>>>>>
>>>>>>> </canvas>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Let's assume that " mycustomclass " contains a number of
>>>>>>> resources,
>>>>>>> and that you ( as a developer )
>>>>>>> only want to change one of those resources . The simplest
>>>>>>> method to
>>>>>>> accomplish this would be ...
>>>>>>>
>>>>>>>
>>>>>>> <canvas>
>>>>>>>
>>>>>>>
>>>>>>> <include name="myCustomLibrary" />
>>>>>>>
>>>>>>>
>>>>>>> <!-- override resource definition "lowerRightCorner_rsc" defined
>>>>>>> earlier in myresouces.lzx -->
>>>>>>> <resource name="lowerRightCorner"
>>>>>>> src="my_new_path/my_lower_right_corner.jpg" />
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <!-- instance of mycustomclass that will now display
>>>>>>> the new resource based on the unchanged css selector
>>>>>>> -->
>>>>>>> <mycustomclass />
>>>>>>>
>>>>>>>
>>>>>>> </canvas>
>>>>>>>
>>>>>>>
>>>>>>> Currently, this code would cause a compiler warning. To avoid
>>>>>>> these
>>>>>>> warnings ( without changing OpenLaszlo ) the resouces.lzx
>>>>>>> file(s) and
>>>>>>> possibly the library .lzx would have to be edited.
>>>>>>>
>>>>>>>
>>>>>>> If instead, we allow for resource overriding, then ...
>>>>>>>
>>>>>>>
>>>>>>> 1) the original CSS and resource files will remain unchanged
>>>>>>> 2) The old resource for " lowerRightCorner" would NOT be
>>>>>>> included in
>>>>>>> the app
>>>>>>> 3) There would be clean separation between external
>>>>>>> libraries and the
>>>>>>> skinning of theses libraries included in an application.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>
More information about the Laszlo-user
mailing list