Standalone Tiles: Status and Call for Help

[Greg Reddin-3]

I've just checked in the last taglib refactoring work that I can  
think of.  That turned out to be a much smaller chunk of work than I  
had thought.  If you're following the wiki page[1] that means  
Milestone 2 in the 4-step process to release is largely complete.  
There's one remaining gaping hole that worries me.  In all the  
refactoring I've done almost all the use cases in my applications  
have worked without issue.  But I suspect I'm only scratching the  
surface of what you can do with Tiles and I don't have much  
confidence that the other stuff will work yet.

So, if there are people willing to help, I think we can take the  
development in 2 simultaneous directions:  1) building test suites  
and 2) moving on to Milestone 3: Remove Servlet API dependencies.  
Ideally, I'd like to see test cases passing before we move on the  
Milestone 3, but in the interest of getting things done, I see no  
reason we can't start accepting patches for it.

As for the test cases, I'm not very familiar with Cactus or some  
other web app testing packages.  So to save time, I've been testing  
using a simple web application and clicking through.  I will  
eventually move these tests to a better testing platform, but the  
current method is working for now.  You can see a very limited list  
of things I'm currently testing for on the wiki page.  I'll try to  
add the rest.  I can also check my test app into the sandbox if it  
will help.  Maybe someone can go ahead and start the process of  
converting them to Cactus or whatever they need to be.  In the  
meantime, I'd love to hear use cases that are not yet documented so I  
can test for them.  Please send me your use cases.  I'll accept them  
offlist either described in an email or with sample JSPs, or post  
them to the list, or add them to the wiki page.  I'll feel a lot  
better about things if I have a more comprehensive set of tests.

In addition I'm sure there are things that have been raised that I  
haven't addressed. especially from Antonio Petrelli.  Please let me  
know of those.

Thanks,
Greg

[1] http://wiki.apache.org/struts/StandaloneTiles#preview

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gary%20VanMatre]

>From: Greg Reddin <greddin@...>
>
> I've just checked in the last taglib refactoring work that I can
> think of. That turned out to be a much smaller chunk of work than I
> had thought. If you're following the wiki page[1] that means
> Milestone 2 in the 4-step process to release is largely complete.
> There's one remaining gaping hole that worries me. In all the
> refactoring I've done almost all the use cases in my applications
> have worked without issue. But I suspect I'm only scratching the
> surface of what you can do with Tiles and I don't have much
> confidence that the other stuff will work yet.
>
> So, if there are people willing to help, I think we can take the
> development in 2 simultaneous directions: 1) building test suites
> and

I wonder if the shale test framework can be leveraged here.  There are mock objects for the servlet API.

>2) moving on to Milestone 3: Remove Servlet API dependencies.
> Ideally, I'd like to see test cases passing before we move on the
> Milestone 3, but in the interest of getting things done, I see no
> reason we can't start accepting patches for it.
>

What did you have in mind here?  Are you think about something similar to the JSF ExternalContext object?  

http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockExternalContext.java?view=markup


Gary

> As for the test cases, I'm not very familiar with Cactus or some
> other web app testing packages. So to save time, I've been testing
> using a simple web application and clicking through. I will
> eventually move these tests to a better testing platform, but the
> current method is working for now. You can see a very limited list
> of things I'm currently testing for on the wiki page. I'll try to
> add the rest. I can also check my test app into the sandbox if it
> will help. Maybe someone can go ahead and start the process of
> converting them to Cactus or whatever they need to be. In the
> meantime, I'd love to hear use cases that are not yet documented so I
> can test for them. Please send me your use cases. I'll accept them
> offlist either described in an email or with sample JSPs, or post
> them to the list, or add them to the wiki page. I'll feel a lot
> better about things if I have a more comprehensive set of tests.
>
> In addition I'm sure there are things that have been raised that I
> haven't addressed. especially from Antonio Petrelli. Please let me
> know of those.
>
> Thanks,
> Greg
>
> [1] http://wiki.apache.org/struts/StandaloneTiles#preview 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

[Greg Reddin-3]

On Mar 21, 2006, at 1:00 PM, Gary VanMatre wrote:

> I wonder if the shale test framework can be leveraged here.  There  
> are mock objects for the servlet API.

I need to take a closer look at that.  I'm using Struts Test Case in  
a few places in Standalone Tiles already.

>> 2) moving on to Milestone 3: Remove Servlet API dependencies.
>> Ideally, I'd like to see test cases passing before we move on the
>> Milestone 3, but in the interest of getting things done, I see no
>> reason we can't start accepting patches for it.
>>
>>
>
> What did you have in mind here?  Are you think about something  
> similar to the JSF ExternalContext object?

Yep.  That and the Commons Chain WebContext set of classes.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gary%20VanMatre]

>From: Greg Reddin <greddin@...>
>
>
> On Mar 21, 2006, at 1:00 PM, Gary VanMatre wrote:
>
> > I wonder if the shale test framework can be leveraged here. There
> > are mock objects for the servlet API.
>
> I need to take a closer look at that. I'm using Struts Test Case in
> a few places in Standalone Tiles already.
>

Oh yeah, I forgot about the struts action mock objects.  

 

> >> 2) moving on to Milestone 3: Remove Servlet API dependencies.
> >> Ideally, I'd like to see test cases passing before we move on the
> >> Milestone 3, but in the interest of getting things done, I see no
> >> reason we can't start accepting patches for it.
> >>
> >>
> >
> > What did you have in mind here? Are you think about something
> > similar to the JSF ExternalContext object?
>
> Yep. That and the Commons Chain WebContext set of classes.
>

I suppose that the choice of the context object could favor action versus shale for a test framework.  

Since I'm in the JSF fan club, I'd argue that we could implement the ExternalContext interface since the JSF API will soon be a given.
   

Gary

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

[Greg Reddin-3]

On Mar 21, 2006, at 4:45 PM, Gary VanMatre wrote:

> I suppose that the choice of the context object could favor action  
> versus shale for a test framework.
>
> Since I'm in the JSF fan club, I'd argue that we could implement  
> the ExternalContext interface since the JSF API will soon be a given.

I haven't thought about implementing it directly.  That's  
interesting.  I'd proceed cautiously though.  My thinking (hope this  
is not news to anyone) is that Standalone Tiles will eventually just  
be "Tiles" :-)  As such I hope it is useful to everyone who is  
currently using Tiles, including Struts Action, WebWork, etc.  I  
wouldn't want to do anything that would make this impossible, or even  
difficult.  At the same time I don't want to reinvent (or subclass)  
the wheel so I'm open to ideas.

Greg

PS: Not to open up another tanker of worms, but is it possible to be  
in the the JSF and action fan club at the same time?  Hmmm.  
Conflicted, I am.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gary%20VanMatre]

>From: Greg Reddin <greddin@...>
>
>
> On Mar 21, 2006, at 4:45 PM, Gary VanMatre wrote:
>
> > I suppose that the choice of the context object could favor action
> > versus shale for a test framework.
> >
> > Since I'm in the JSF fan club, I'd argue that we could implement
> > the ExternalContext interface since the JSF API will soon be a given.
>
> I haven't thought about implementing it directly. That's
> interesting. I'd proceed cautiously though. My thinking (hope this
> is not news to anyone) is that Standalone Tiles will eventually just
> be "Tiles" :-) As such I hope it is useful to everyone who is
> currently using Tiles, including Struts Action, WebWork, etc. I
> wouldn't want to do anything that would make this impossible, or even
> difficult. At the same time I don't want to reinvent (or subclass)
> the wheel so I'm open to ideas.
>

Yeah, I agree that you will want to choose something in the middle.


> Greg
>
> PS: Not to open up another tanker of worms, but is it possible to be
> in the the JSF and action fan club at the same time? Hmmm.
> Conflicted, I am.
>

Yes, I am too.  JSF very much I like but pay the bills is now action for me.

Gary

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

[craigmcc]

On 3/21/06, Greg Reddin <greddin@...> wrote:

>
>
> On Mar 21, 2006, at 4:45 PM, Gary VanMatre wrote:
>
> > I suppose that the choice of the context object could favor action
> > versus shale for a test framework.
> >
> > Since I'm in the JSF fan club, I'd argue that we could implement
> > the ExternalContext interface since the JSF API will soon be a given.
>
> I haven't thought about implementing it directly.  That's
> interesting.  I'd proceed cautiously though.  My thinking (hope this
> is not news to anyone) is that Standalone Tiles will eventually just
> be "Tiles" :-)  As such I hope it is useful to everyone who is
> currently using Tiles, including Struts Action, WebWork, etc.  I
> wouldn't want to do anything that would make this impossible, or even
> difficult.  At the same time I don't want to reinvent (or subclass)
> the wheel so I'm open to ideas.

For a library claiming to be "standalone", I would be a little cautious
about depending on either set of mock object APIs.  That being said, the
Shale test framework mock objects for servlet and JSP stuff can be used even
without JSF in the picture, so it might be a practical choice after all.
But you certainly would not want to program directly to any JSF APIs here.

Greg
>
> PS: Not to open up another tanker of worms, but is it possible to be
> in the the JSF and action fan club at the same time?  Hmmm.
> Conflicted, I am.


It *looks* quite possible to get *some* combinations of benefits, with a
couple of different approaches:

APPROACH 1:

For example, Shale offers an applicaton controller (implemented as a Filter)
that lets you use Commons Chain to define the global pre- and post-
processing that is done on every request (the sort of change you would
implement by modifying RequestProcessor in 1.1/1.2, or the global chain
implementation in 1.3).  On my list of things to investigate is whether that
could be substituted out for a gadget that uses XWork (the action processing
framework that underlies WebWork) to gain access to the cool intercepter
stuff.

The other place that you'd want to hook in is the equivalent of where your
action's execution method gets called, so you can decorate individual logic
paths with local customizations.  Turns out that JSF lets you customize that
as well, so we can do the same sort of trick here.

Jason/Patrick/Don/Ted/Martin -- are any of you guys going to be at TSSJS
later this week?  I'd sure like to sit down and walk through whether this is
as feasible in code as it appears to be on the back of a napkin.

APPROACH 2:

Use the struts-faces library, and focus on just using the components parts
of JSF while using the framework part from Struts.  If you look at the
internal architecture it ends up looking a little odd (the JSF front
controller is in front of the Struts front controller), but it can actually
work.  This is also a reasonable approach if you are required to migrate an
existing Struts based app to JSF and cannot take the time to do it all over
again.

Craig

[Martin Cooper-2]

On 3/21/06, Craig McClanahan <craigmcc@...> wrote:

>
> On 3/21/06, Greg Reddin <greddin@...> wrote:
> >
> >
> > On Mar 21, 2006, at 4:45 PM, Gary VanMatre wrote:
> >
> > > I suppose that the choice of the context object could favor action
> > > versus shale for a test framework.
> > >
> > > Since I'm in the JSF fan club, I'd argue that we could implement
> > > the ExternalContext interface since the JSF API will soon be a given.
> >
> > I haven't thought about implementing it directly.  That's
> > interesting.  I'd proceed cautiously though.  My thinking (hope this
> > is not news to anyone) is that Standalone Tiles will eventually just
> > be "Tiles" :-)  As such I hope it is useful to everyone who is
> > currently using Tiles, including Struts Action, WebWork, etc.  I
> > wouldn't want to do anything that would make this impossible, or even
> > difficult.  At the same time I don't want to reinvent (or subclass)
> > the wheel so I'm open to ideas.
>
>
> For a library claiming to be "standalone", I would be a little cautious
> about depending on either set of mock object APIs.  That being said, the
> Shale test framework mock objects for servlet and JSP stuff can be used
> even
> without JSF in the picture, so it might be a practical choice after all.
> But you certainly would not want to program directly to any JSF APIs here.

I've heard a lot of good things about EasyMock, although I haven't used it
myself.

http://www.easymock.org/

Greg

> >
> > PS: Not to open up another tanker of worms, but is it possible to be
> > in the the JSF and action fan club at the same time?  Hmmm.
> > Conflicted, I am.
>
>
> It *looks* quite possible to get *some* combinations of benefits, with a
> couple of different approaches:
>
> APPROACH 1:
>
> For example, Shale offers an applicaton controller (implemented as a
> Filter)
> that lets you use Commons Chain to define the global pre- and post-
> processing that is done on every request (the sort of change you would
> implement by modifying RequestProcessor in 1.1/1.2, or the global chain
> implementation in 1.3).  On my list of things to investigate is whether
> that
> could be substituted out for a gadget that uses XWork (the action
> processing
> framework that underlies WebWork) to gain access to the cool intercepter
> stuff.
>
> The other place that you'd want to hook in is the equivalent of where your
> action's execution method gets called, so you can decorate individual
> logic
> paths with local customizations.  Turns out that JSF lets you customize
> that
> as well, so we can do the same sort of trick here.
>
> Jason/Patrick/Don/Ted/Martin -- are any of you guys going to be at TSSJS
> later this week?  I'd sure like to sit down and walk through whether this
> is
> as feasible in code as it appears to be on the back of a napkin.

Sadly, no. My employer appears to be increasingly stingy on conferences this
year. ;-(

--
Martin Cooper


APPROACH 2:

>
> Use the struts-faces library, and focus on just using the components parts
> of JSF while using the framework part from Struts.  If you look at the
> internal architecture it ends up looking a little odd (the JSF front
> controller is in front of the Struts front controller), but it can
> actually
> work.  This is also a reasonable approach if you are required to migrate
> an
> existing Struts based app to JSF and cannot take the time to do it all
> over
> again.
>
> Craig
>
>

[Antonio Petrelli]

Greg Reddin ha scritto:
> In addition I'm sure there are things that have been raised that I
> haven't addressed. especially from Antonio Petrelli.

Uh? Who called me? I obviously will be pleased to help if you want :-) I
could take my experience with Dimensions to add some missing pieces.
Anyway, if I will be so lucky to help you all, notice that I am very
busy, I can work on it for about 1-2 hour a day.
Ciao
Antonio


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Antonio Petrelli]

Antonio Petrelli ha scritto:
> I can work on it for about 1-2 hour a day.
I meant one or two hours a day, not half an hour... It was a bit
ambiguous...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Reddin-3]

On Mar 22, 2006, at 2:51 AM, Antonio Petrelli wrote:

> Antonio Petrelli ha scritto:
>
>> I can work on it for about 1-2 hour a day.
>>
> I meant one or two hours a day, not half an hour... It was a bit  
> ambiguous...

If you have that much time to spend on it then I envy you :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Antonio Petrelli]

Greg Reddin ha scritto:

>
> On Mar 22, 2006, at 2:51 AM, Antonio Petrelli wrote:
>
>> Antonio Petrelli ha scritto:
>>
>>> I can work on it for about 1-2 hour a day.
>>>
>> I meant one or two hours a day, not half an hour... It was a bit
>> ambiguous...
>
> If you have that much time to spend on it then I envy you :-)

But not on weekends, I would like dedicate those days for nicer things
than Tiles, my girlfriend for example :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Reddin-3]

On Mar 22, 2006, at 2:35 AM, Antonio Petrelli wrote:

> Uh? Who called me? I obviously will be pleased to help if you  
> want :-) I could take my experience with Dimensions to add some  
> missing pieces.
> Anyway, if I will be so lucky to help you all, notice that I am  
> very busy, I can work on it for about 1-2 hour a day.

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.  If it's still an  
issue for you let me know and we can reopen the discussion (probably  
with a Bugzilla ticket).  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.  You're the only one that was  
extending the original architecture and has spoken up about  
incompatibilities with the new version.

Thanks,
Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Reddin-3]

On Mar 22, 2006, at 8:51 AM, Antonio Petrelli wrote:

> Greg Reddin ha scritto:
>
>>
>> On Mar 22, 2006, at 2:51 AM, Antonio Petrelli wrote:
>>
>>
>>> Antonio Petrelli ha scritto:
>>>
>>>
>>>> I can work on it for about 1-2 hour a day.
>>>>
>>>>
>>> I meant one or two hours a day, not half an hour... It was a bit  
>>> ambiguous...
>>>
>>
>> If you have that much time to spend on it then I envy you :-)
>>
> But not on weekends, I would like dedicate those days for nicer  
> things than Tiles, my girlfriend for example :-)

+1. For me it's complicated because I'm married to my girlfriend :-)  
And there's three little people who think they live here...  And, not  
only that, but they think I should spend time with *them* on the  
weekends :-)  What's up with that?  And why don't campgrounds have  
wireless access yet?

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Reddin-3]

On Mar 21, 2006, at 6:04 PM, Craig McClanahan wrote:

> For a library claiming to be "standalone", I would be a little  
> cautious
> about depending on either set of mock object APIs.

Certainly, no such dependencies should be in the core software, but  
dependencies in the test cases are acceptable, right?  I suppose we  
could modify the existing tests to use mock implementations of the  
context once we get that figured out.  Even so, context  
implementations that work with Servlet API, Faces, Portlet, etc. will  
need tests.  Does all that stuff need to be optional?

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Antonio Petrelli]

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Greg Reddin-3]

On Mar 22, 2006, at 9:41 AM, Antonio Petrelli wrote:

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

That's what I was wondering.  I never had a chance to really look at  
your solution to determine if the current code is the desired  
effect.  If you were to post a ticket, it will ensure that this gets  
looked at before a release happens.  If you don't it may get  
overlooked.  After looking at the problem again I still don't fully  
understand it so I will have to look deeper, in which case it may get  
lost again if you don't open a ticket :-)

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

My gut feeling is that you might have to extend DefinitionsFactory or  
ComponentDefinitions or something like that to make this happen.  I  
can't say for sure without looking deeper.  I would look closely at  
ComponentDefinitions and see if it can happen there.

Greg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[craigmcc]

On 3/22/06, Greg Reddin <greddin@...> wrote:

>
>
> On Mar 21, 2006, at 6:04 PM, Craig McClanahan wrote:
>
> > For a library claiming to be "standalone", I would be a little
> > cautious
> > about depending on either set of mock object APIs.
>
> Certainly, no such dependencies should be in the core software, but
> dependencies in the test cases are acceptable, right?  I suppose we
> could modify the existing tests to use mock implementations of the
> context once we get that figured out.  Even so, context
> implementations that work with Servlet API, Faces, Portlet, etc. will
> need tests.  Does all that stuff need to be optional?

I was rambling a bit in that paragraph (and I seem to have changed my mind
about half way through :-) ... let me try to be a little clearer.

The Shale test framework classes include mock implementations of essentially
all APIs in the servlet spec (as well as JSF, but that's not really relevant
here).  As such, it can be used as a source of things like
MockServletContext, MockHttpServletRequest, and so on.  It *should* be
possible to use this jar file for Tiles tests, even if you don't have
jsf-api.jar in the classpath, as long as you don't try to use things like
MockFacesContext.  The end result is we should be able to construct JUnit
based tests for nearly everything in standalone Tiles, without the
complexity of Cactus tests.  (For in container testing, I prefer to set up a
"real" app and then exercise it with things like HtmlUnit.)

The only place it might fall down a little for you is in testing custom tags
... there's no current implementatino of things like MockPageContext.
That's a solvable problem, though, by just writing a few more classes.

Greg


Craig

[Greg Reddin-3]

On Mar 22, 2006, at 11:45 AM, Craig McClanahan wrote:

> The Shale test framework classes include mock implementations of  
> essentially
> all APIs in the servlet spec (as well as JSF, but that's not really  
> relevant
> here).  As such, it can be used as a source of things like
> MockServletContext, MockHttpServletRequest, and so on.  It *should* be
> possible to use this jar file for Tiles tests, even if you don't have
> jsf-api.jar in the classpath, as long as you don't try to use  
> things like
> MockFacesContext.  The end result is we should be able to construct  
> JUnit
> based tests for nearly everything in standalone Tiles, without the
> complexity of Cactus tests.  (For in container testing, I prefer to  
> set up a
> "real" app and then exercise it with things like HtmlUnit.)
>
> The only place it might fall down a little for you is in testing  
> custom tags
> ... there's no current implementatino of things like MockPageContext.
> That's a solvable problem, though, by just writing a few more classes.

Ok, thanks for the clarification.  I'm cool with that.

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Paul Benedict]

>> there's no current implementatino of things like MockPageContext

Craig, there is one in the Spring Framework library. :) Spring contains mocks
of the servlet api. The library doesn't depend on Spring, but they have
their own mocks. Spring uses the MockPageContext to write unit tests for
their tag libraries. Greg I recommend you look into this.

Paul

--- Craig McClanahan <craigmcc@...> wrote:

> On 3/22/06, Greg Reddin <greddin@...> wrote:
> >
> >
> > On Mar 21, 2006, at 6:04 PM, Craig McClanahan wrote:
> >
> > > For a library claiming to be "standalone", I would be a little
> > > cautious
> > > about depending on either set of mock object APIs.
> >
> > Certainly, no such dependencies should be in the core software, but
> > dependencies in the test cases are acceptable, right?  I suppose we
> > could modify the existing tests to use mock implementations of the
> > context once we get that figured out.  Even so, context
> > implementations that work with Servlet API, Faces, Portlet, etc. will
> > need tests.  Does all that stuff need to be optional?
>
>
> I was rambling a bit in that paragraph (and I seem to have changed my mind
> about half way through :-) ... let me try to be a little clearer.
>
> The Shale test framework classes include mock implementations of essentially
> all APIs in the servlet spec (as well as JSF, but that's not really relevant
> here).  As such, it can be used as a source of things like
> MockServletContext, MockHttpServletRequest, and so on.  It *should* be
> possible to use this jar file for Tiles tests, even if you don't have
> jsf-api.jar in the classpath, as long as you don't try to use things like
> MockFacesContext.  The end result is we should be able to construct JUnit
> based tests for nearly everything in standalone Tiles, without the
> complexity of Cactus tests.  (For in container testing, I prefer to set up a
> "real" app and then exercise it with things like HtmlUnit.)
>
> The only place it might fall down a little for you is in testing custom tags
> ... there's no current implementatino of things like MockPageContext.
> That's a solvable problem, though, by just writing a few more classes.
>
> Greg
>
>
> Craig
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...