Greg Reddin ha scritto:
Seems a couple of weeks ago you sent an email about a potential bug or
missing piece. We had a short exchange about it and it fell off my
radar as I was trying to make sure I understood what your need was.
It was something about Tiles definitions with extends and path
attributes. You may have even sent a patch and I was trying to
determine why it was needed when I lost the thread.
Fortunately I marked the thread as "important" :-P I will repost it at
the end of this mail.
If it's still an issue for you let me know and we can reopen the
discussion (probably with a Bugzilla ticket).
It is not an issue anymore because I wrote a workaround in Dimensions
code. It simply clears the "path" attribute of a definition when it's
extended (overloaded) when the extended definition does not specify the
"path" attribute.
The workaround is not very elegant, I don't know if it deserves a
Bugzilla ticket, because, maybe, the current one is the desidered effect...
Also, if you could let me know if there are places where Standalone
Tiles is still not viable for Dimensions I'd like to try to address
those issues.
I'll try to see if Dimensions can be adapted to the new form of Tiles,
but I need to investigate deeply. But maybe you can answer a question:
can I have a different definition for the same definition name? That is,
if I want to get a definition as an object by giving its name, I want to
check some circumstances and then decide which is the correct definition
object to return to the caller. Can I do something like this?
You're the only one that was extending the original architecture and
has spoken up about incompatibilities with the new version.
Include Aaron Roller, the first Dimensions developer :-)
Thanks,
Thanks to you
Greg
Antonio
------------------------------------------------------------------------------------------
Thread: [Tiles] Definition with extends and path attributes
First mail:
<snip>
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.
</snip>
**************
Second mail (by you, i.e. Greg)
<snip>
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?
</snip>
**********************
Third mail (by me) (at the end there is the patch):
<snip>
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?
</snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]