[Laszlo-user] [Laszlo-dev] Need to be able to override resource declarations in OpenLaszlo without warnings.

[P T Withington]

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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>