Re: [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.