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

[Elliot Winard]

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