RE: [Tiles] Definition with extends and path attributes

[David G. Friedman]

Antonio,

Could you use a Controller class to change the path="..." attribute for 
yourself based upon some criteria or variable
you set in scope (request/session).  With that method, you could have one base 
class instead of using the same name
twice in two different files.  If you are interested in this method, see the 
Tiles Advanced Features PDF.

Regards,
David

-----Original Message-----
From: Antonio Petrelli [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 31, 2006 10:25 AM
To: Struts Users Mailing List
Subject: Re: [Tiles] Definition with extends and path attributes


Greg Reddin ha scritto:
>
> On Jan 31, 2006, at 8:09 AM, Antonio Petrelli wrote:
>
>> Does a definition such as this have sense?
>>
>> <definition name="myName" extends="myExtends" path="path.jsp">
>
> I've personally never had a situation like this where I extend a tile
> and redefine the path at the same time.  I've always extended a tile
> definition and overridden only the attributes.

Me too, this is because I asked you this.

> To make sure I have this straight: You have "page.index" defined twice
> in 2 different files?

Right

> Why not do something like this?
> ...
> 2nd file:
> <definition name="page.index.bug" path="/layout/three_rows_layout.jsp"
> extends="page.index" />
>
> Is it a requirement that you always reference "page.index" but get
> different definitions in different contexts or can you reference
> "page.index.bug" when you want the 3 row layout?
I need to use always page.index, because which "page.index" is decided
at runtime. In particular, the "base" page.index is displayed for HTML
devices, the "extended" page.index is displayed for PDAs (as usual I am
referring to Dimensions).
>
>> When I use XmlDefinitionSet.extend method, the "page.index"
>> definition has both the "extends" (in fact "inherit") and "path"
>> attributes! After doing "resolveInheritances" it does not solve the
>> problem.
>> I think the (possible) bug is in XmlDefinition.overload, where the
>> attributes are simply copied and not checked.
>
> That's definitely a possibility.  Can you verify it?

In XmlDefinitionsSet.extend I find this code:

<snip>
      XmlDefinition childInstance = (XmlDefinition)i.next();
      XmlDefinition parentInstance =
getDefinition(childInstance.getName() );
      if( parentInstance != null )
        {
        parentInstance.overload( childInstance );
        }
       else
        putDefinition( childInstance );
</snip>

So, if there is no parent definition, it is simply put, otherwise it is
"overloaded".
The "overload" method is:

<snip>
  public void overload( XmlDefinition child )
    {
    if( child.getPath() != null )
      {
      path = child.getPath();
      }
    if( child.getExtends() != null )
      {
      inherit = child.getExtends();
      }
    if( child.getRole() != null )
      {
      role = child.getRole();
      }
    if( child.getController()!=null )
      {
      controller = child.getController();
      controllerType =  child.getControllerType();
      }
      // put all child attributes in parent.
    attributes.putAll( child.getAttributes());
    }
}
</snip>

That is, for each property of "child", if it is not null, it is copied,
without modifying the original. IMHO if the "inherit" property of
"child" is not null, the "path" attribute
of the original definition must be set to null (if child.path is null)
or it should match child.path.
So the code could be:

<snip>
  public void overload( XmlDefinition child )
    {
    if( child.getExtends() != null )
      {
      inherit = child.getExtends();
      path = child.getPath(); //It's ok even if it is null
      }
    else if( child.getPath() != null )
      {
      path = child.getPath();
      }
...
</snip>

Obviously, after all XmlDefinitionsSet.resolveInheritances must be called.
What do you think?
>
> Thanks,
Thanks to you :-)
> Greg
Antonio


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]