You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Antonio Petrelli <br...@tariffenet.it> on 2006/01/31 15:09:17 UTC
[Tiles] Definition with extends and path attributes
Does a definition such as this have sense?
<definition name="myName" extends="myExtends" path="path.jsp">
...
</definition>
This is just because I have a problem with inheritance between multiple
files.
Say I have two files, where the second extends the first.
The first definition file contains:
<definition name="page.index" path="/layout/classic_layout.jsp">
<put name="top" value="/tiles/top.jsp"/>
<put name="left" value="/tiles/fourth.jsp"/>
<put name="body" value="/tiles/login.jsp" />
</definition>
The second file contains:
<definition name="page.index.bug" path="/layout/three_rows_layout.jsp" />
<definition name="page.index" extends="page.index.bug">
<put name="top" value="/tiles/top_pda.jsp"/>
<put name="left" value="/tiles/fourth.jsp"/>
<put name="body" value="/tiles/login.jsp" />
</definition>
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.
Thanks in advance
Antonio Petrelli
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Tiles] Definition with extends and path attributes
Posted by Antonio Petrelli <br...@tariffenet.it>.
David G. Friedman ha scritto:
> 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.
>
Thanks but no thanks :-P
The power of Dimensions is that the "real" definition is decided AFTER
its name is decided, so that you can use the same name for different
appearances (one for PC with browser, one for PDAs, etc.)
Anyway I don't want to mix up view and controller parts.
Thank you anyway :-)
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [Tiles] Definition with extends and path attributes
Posted by "David G. Friedman" <hu...@ix.netcom.com>.
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:brenmcguire@tariffenet.it]
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Tiles] Definition with extends and path attributes
Posted by Antonio Petrelli <br...@tariffenet.it>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Tiles] Definition with extends and path attributes
Posted by Greg Reddin <gr...@apache.org>.
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. But I can see merit
to the approach. If the framework does not currently support it, it
probably should.
> <definition name="page.index" path="/layout/classic_layout.jsp">
> <put name="top" value="/tiles/top.jsp"/>
> <put name="left" value="/tiles/fourth.jsp"/>
> <put name="body" value="/tiles/login.jsp" />
> </definition>
>
>
> The second file contains:
>
> <definition name="page.index.bug" path="/layout/
> three_rows_layout.jsp" />
> <definition name="page.index" extends="page.index.bug">
> <put name="top" value="/tiles/top_pda.jsp"/>
> <put name="left" value="/tiles/fourth.jsp"/>
> <put name="body" value="/tiles/login.jsp" />
> </definition>
To make sure I have this straight: You have "page.index" defined
twice in 2 different files? Why not do something like this?
First file:
<definition name="page.index" path="/layout/classic_layout.jsp">
<put name="top" value="/tiles/top.jsp"/>
<put name="left" value="/tiles/fourth.jsp"/>
<put name="body" value="/tiles/login.jsp" />
</definition>
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?
> 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?
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org