You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Duong BaTien <du...@gmail.com> on 2005/04/02 00:11:07 UTC
[Shale]: , , DialogController and Tiles
Hello Craig:
Well, this is Friday so we can take it easy on the debate between Struts
and Jsf. This is about Struts-Shale, Jsf and Tiles.
First, thank you for your contributions in CoR commons-chain and Shale.
I had some time to re-visit shale and have successfully implemented
shale as a servlet filter, its view controller with myfaces
JspTilesViewHandlerImpl, and DialogController. Some questions:
1) The logon Dialog demonstrates an implementation of DialogController
using hard-coded methods as entry points. Is there any thought of a
generic Dialog bean whose actions and processes are assembled on-demand
via CoR/IoC?
2) Association between view id and viewController is quite handy. I am
able to associate each view id, assembled from complex tiles fragments,
with a specialized viewController that pull part of the data from a
dialogController. All tiles fragment use Jsf <f:subview>. Now moving to
the shale <s:subview>, is it intended to replace jsf <f:subview> if more
than 1 fragments requires viewController? I have not tested this case
with myfaces tile viewHandler. I think i should wait for shale custom
ViewHandler that works with tiles.
3) If <s:subview> is intended to replace <f:subview> to work with tiles,
can it be done in such a way that each request needs to instantiate only
2 request-scope viewControllers for 2 fragments (portlet menu and its
display fragments depending on which portlet user clicks)?
BaTien
DBGROUPS
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale]: , , DialogController and Tiles
Posted by Duong BaTien <du...@gmail.com>.
Craig McClanahan wrote:
>On Apr 1, 2005 2:11 PM, Duong BaTien <du...@gmail.com> wrote:
>
>
>>Hello Craig:
>>
>>Well, this is Friday so we can take it easy on the debate between Struts
>>and Jsf. This is about Struts-Shale, Jsf and Tiles.
>>
>>First, thank you for your contributions in CoR commons-chain and Shale.
>>I had some time to re-visit shale and have successfully implemented
>>shale as a servlet filter, its view controller with myfaces
>>JspTilesViewHandlerImpl, and DialogController. Some questions:
>>
>>1) The logon Dialog demonstrates an implementation of DialogController
>>using hard-coded methods as entry points. Is there any thought of a
>>generic Dialog bean whose actions and processes are assembled on-demand
>>via CoR/IoC?
>>
>>
>
>What would the method binding expression look like in this case?
>Today, the last component of this expression is the name of the method
>to be called, and you'd either have to maintain that or provide some
>sort of custom method binding expression evaluator that did something
>like creating a context and then firing off a chain.
>
>It might just be simpler to compose a Context object, and fire off the
>appropriate chain, yourself inside the event handling methods. With a
>suitable helper function, each event handling method could be a simple
>one liner.
>
>On a parallel note, I'm quite intrigued by the Web Flow project in
>Swing's sandbox, and am trying to carve out enough time to integrate
>it into Shale. It is much more fleshed out than DialogController, and
>includes nice concepts like nested subflows.
>
>
>
Do you mean Spring's sandbox? I will take a look at it.
>>2) Association between view id and viewController is quite handy. I am
>>able to associate each view id, assembled from complex tiles fragments,
>>with a specialized viewController that pull part of the data from a
>>dialogController. All tiles fragment use Jsf <f:subview>. Now moving to
>>the shale <s:subview>, is it intended to replace jsf <f:subview> if more
>>than 1 fragments requires viewController? I have not tested this case
>>with myfaces tile viewHandler. I think i should wait for shale custom
>>ViewHandler that works with tiles.
>>
>>
>
>Yes, the intent is that <s:subview> would replace <f:subview> in order
>to provide the lifecycle event calls for every fragment's
>ViewController bean. If/when David gets done on extracting Tiles out
>of Struts, and integrating it with Shale, we'll likely want a
>component that does a combination of what <s:subview> and
><tiles:insert> do, so the developer won't have to use both.
>
>
>
Wow :-) i am waiting for this.
>The last time I tried (pre-1.0.9 though) the entire Shale use cases
>example worked correctly with MyFaces as well as with the JSF RI. In
>particular, there's a portion of the unit tests that verifies the
>event calls occur in the correct order.
>
>
>
But that does not have myfaces tiles viewHandler. I think will be broken
under the current tiles viewHandler.
>>3) If <s:subview> is intended to replace <f:subview> to work with tiles,
>>can it be done in such a way that each request needs to instantiate only
>>2 request-scope viewControllers for 2 fragments (portlet menu and its
>>display fragments depending on which portlet user clicks)?
>>
>>
>
>I suppose you could do that by specifying two subviews in the "outer"
>page prepared by the portal server; but I want the ability to use
>subviews *inside* a single portlet as well -- hence the desire to
>support an arbitrary number of initialized ViewControllers per
>request.
>
>
This is the ideal case as long as it is NOT hard hooked. So a portlet
application does not have to fire up request-scope viewControllers when
not needed.
>
>
>>BaTien
>>DBGROUPS
>>
>>
>>
>
>Craig
>
>
Thanks. Have a good weekend.
BaTien
DBGROUPS
>---------------------------------------------------------------------
>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: [Shale]: , , DialogController and Tiles
Posted by Duong BaTien <du...@gmail.com>.
Craig McClanahan wrote:
>On Apr 2, 2005 11:25 AM, NetSQL <ma...@friendvu.com> wrote:
>
>
>>Craig McClanahan wrote:
>>
>>
>>
>>>And there's even JSF components around that do this sort of thing too :-).
>>>
>>>
>>>
>>AFAIK JSF was not designed for client rendering (hence "Server" faces,
>>not "Client" faces). It can be done in the same way one can get JSP or
>>Servlet API to render on the Client.
>>
>>
>
>See my response to BaTien for some pointers to existing libraries of
>JSF components that already do the kind of thing we are talking about.
>
>
>
>>Please somone correct me if I am wrong.
>>
>>
>
>The "server" part of the name JavaServer Faces refers to the fact that
>you are constructing components that do two things on the server side:
>
>* Render some sort of representation of themselves
>
>* Trigger events on an HTTP request (after restoring the
> previous server side state, if any).
>
>plus a standard MVC-style front controller framework to manage the
>HTTP transactions (including a request processing lifecycle, event
>management, server-side validation, and navigation that anyone
>familiar with Struts will see is similar to what any front controller
>framework provides).
>
>The key thing many newcomers miss is that JSF itself is totally
>agnostic about what kind of representation is created (other than the
>fact that there are a few standard components that are HTML specific,
>primarily to get you started). You can certainly render simple HTML
>widgets directly on the server, as these standard components do. But
>you can do a lot more.
>
>Let's say you wanted to build a dropdown control that, in addition to
>the typical behavior of a dropdown list, had a way to refresh the
>dropdown list contents via an asynchronous call to the server (so you
>don't have to refresh the entire page). Instead of creating the
>markup itself, you'd generate the JavaScript code (or, more likely, a
>call into some JavaScript library that is already included in your
>application). The JavaScript code would use DHTML to construct the
>dropdown list component and dynamically add it to the client side DOM,
>and would also offer a method that could be triggered (from some other
>client side JavaScript) to go refill the list asynchronously.
>
>It's still a server side component, but instead of rendering markup
>you are rendering client side code that creates markup.
>
>However, because it conforms to a standard component API, you have
>made it easy for a page developer to construct a user interface using
>these components, without that developer having to understand all the
>intricacies of JavaScript and DHTML, and how it actually works under
>the covers. And, that developer can intermix components from other
>JSF component libraries as well, because they all share a common API
>and runtime environment. The developer can even use a tool like
>Creator that makes assembling a page an exercise in drag-n-drop, and
>configuring the component properties.
>
>Finally, with JSF you get to leverage the front controller both for
>form submits and for responding to the background XmlHttpRequest
>calls.
>
>Readers familiar with Tapestry will be chuckling about now, saying "we
>can do that too". And they are right ... Tapestry provides a server
>side UI component framework that can do all this as well --
>demonstrating that a component oriented architecture can provide a
>powerful basis for creating sophisticated applications, without
>exposing all the nitty gritty details to the developer. Indeed, it is
>the lack of a component architecture in Strust 1.x that requires you
>to go assemble all of the pieces as tag libraries and filters and
>such, as well as have to do other things like data conversion
>yourself.
>
>JSF (at least in version 1.0 and 1.1) doesn't offer any of the
>standard JavaScript libraries to help you build components like this.
>Instead, it lets you write components that leverage such libraries
>that already exist in order to allow page authors to easily construct
>pages that use such libraries, without having to have a deep
>understanding of how all that JavaScript and DHTML stuff actually
>functions.
>
>Doing more to support building components like this more easily,
>however, is definitely on the table in JSF 2.0.
>
>In the mean time, I'll be doing more in Shale to provide a JSF-based
>runtime environment for these kinds of components -- after all, an
>XmlHttpRequest request can be processed through a front controller
>just like a form submit can be, and mapping the incoming event to the
>corresponding processing logic is pretty much the same for both cases.
>
>
Hello Craig:
You answer to Vic, but many of us - me included - get benefit from this
insight.
BaTien
DBGROUPS
>
>
>>.V
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>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: [Shale]: , , DialogController and Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On Apr 2, 2005 11:25 AM, NetSQL <ma...@friendvu.com> wrote:
> Craig McClanahan wrote:
>
> >
> > And there's even JSF components around that do this sort of thing too :-).
> >
>
> AFAIK JSF was not designed for client rendering (hence "Server" faces,
> not "Client" faces). It can be done in the same way one can get JSP or
> Servlet API to render on the Client.
See my response to BaTien for some pointers to existing libraries of
JSF components that already do the kind of thing we are talking about.
>
> Please somone correct me if I am wrong.
The "server" part of the name JavaServer Faces refers to the fact that
you are constructing components that do two things on the server side:
* Render some sort of representation of themselves
* Trigger events on an HTTP request (after restoring the
previous server side state, if any).
plus a standard MVC-style front controller framework to manage the
HTTP transactions (including a request processing lifecycle, event
management, server-side validation, and navigation that anyone
familiar with Struts will see is similar to what any front controller
framework provides).
The key thing many newcomers miss is that JSF itself is totally
agnostic about what kind of representation is created (other than the
fact that there are a few standard components that are HTML specific,
primarily to get you started). You can certainly render simple HTML
widgets directly on the server, as these standard components do. But
you can do a lot more.
Let's say you wanted to build a dropdown control that, in addition to
the typical behavior of a dropdown list, had a way to refresh the
dropdown list contents via an asynchronous call to the server (so you
don't have to refresh the entire page). Instead of creating the
markup itself, you'd generate the JavaScript code (or, more likely, a
call into some JavaScript library that is already included in your
application). The JavaScript code would use DHTML to construct the
dropdown list component and dynamically add it to the client side DOM,
and would also offer a method that could be triggered (from some other
client side JavaScript) to go refill the list asynchronously.
It's still a server side component, but instead of rendering markup
you are rendering client side code that creates markup.
However, because it conforms to a standard component API, you have
made it easy for a page developer to construct a user interface using
these components, without that developer having to understand all the
intricacies of JavaScript and DHTML, and how it actually works under
the covers. And, that developer can intermix components from other
JSF component libraries as well, because they all share a common API
and runtime environment. The developer can even use a tool like
Creator that makes assembling a page an exercise in drag-n-drop, and
configuring the component properties.
Finally, with JSF you get to leverage the front controller both for
form submits and for responding to the background XmlHttpRequest
calls.
Readers familiar with Tapestry will be chuckling about now, saying "we
can do that too". And they are right ... Tapestry provides a server
side UI component framework that can do all this as well --
demonstrating that a component oriented architecture can provide a
powerful basis for creating sophisticated applications, without
exposing all the nitty gritty details to the developer. Indeed, it is
the lack of a component architecture in Strust 1.x that requires you
to go assemble all of the pieces as tag libraries and filters and
such, as well as have to do other things like data conversion
yourself.
JSF (at least in version 1.0 and 1.1) doesn't offer any of the
standard JavaScript libraries to help you build components like this.
Instead, it lets you write components that leverage such libraries
that already exist in order to allow page authors to easily construct
pages that use such libraries, without having to have a deep
understanding of how all that JavaScript and DHTML stuff actually
functions.
Doing more to support building components like this more easily,
however, is definitely on the table in JSF 2.0.
In the mean time, I'll be doing more in Shale to provide a JSF-based
runtime environment for these kinds of components -- after all, an
XmlHttpRequest request can be processed through a front controller
just like a form submit can be, and mapping the incoming event to the
corresponding processing logic is pretty much the same for both cases.
>
> .V
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale]: , , DialogController and Tiles
Posted by NetSQL <ma...@friendVU.com>.
Craig McClanahan wrote:
>
> And there's even JSF components around that do this sort of thing too :-).
>
AFAIK JSF was not designed for client rendering (hence "Server" faces,
not "Client" faces). It can be done in the same way one can get JSP or
Servlet API to render on the Client.
Please somone correct me if I am wrong.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale]: , , DialogController and Tiles
Posted by Duong BaTien <du...@gmail.com>.
Craig McClanahan wrote:
>>>
>>>
>>Craig:
>>
>>Do you like to speculate and/or share the timing of this?
>>
>>
>
>IBM (RAD) and Oracle (ADF) both have libraries that include components
>for this purpose.
>
>I have seen other libraries as well, from companies like Otrix. My
>favorite example is one of their JSF components, a tree control ...
>but a tree control that is backed by a database of 6000 possible
>entries. The component only downloads the portions of the data needed
>for the currently expanded nodes, and uses asynchronous background
>communication to grab more data when you expand new nodes.
>
>
This sort of things keeps Java developers useful and makes us busy. Thanks.
BaTien
DBGROUPS
>
>
>>BaTien
>>DBGROUPS
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>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: [Shale]: , , DialogController and Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On Apr 2, 2005 1:10 PM, Duong BaTien <du...@gmail.com> wrote:
> Craig McClanahan wrote:
>
> >On Apr 2, 2005 9:53 AM, NetSQL <ma...@friendvu.com> wrote:
> >
> >
> >>Craig McClanahan wrote:
> >>I'm quite intrigued by the Web Flow project in
> >>
> >>
> >>>Swing's sandbox ...
> >>>
> >>>
> >>Not Swing.
> >>Spring or Don Brown's Ajax-Strtus sandbox I assume are both called "Flow".
> >>
> >>
> >>
> >
> >Yes, I meant "Spring". They also recently released a milestone of this code.
> >
> >
> Yes, i did take a quick look at Spring Web Flow. I am looking forward to
> your integration under Shale. One small feature in the workflow that
> seems quite useful is the persistence of each specified step so user
> does not need to start from the beginning.
>
> >
> >
> >>( I am glad it's in the back of your mind Freud. XUL, Flex, XAML, Ajax
> >>(aka DHTML), JDNC all render on the client and improve performance by
> >>offloading rendering from the server.)
> >>
> >>
> >
> >And there's even JSF components around that do this sort of thing too :-).
> >
> >
> >
> Craig:
>
> Do you like to speculate and/or share the timing of this?
IBM (RAD) and Oracle (ADF) both have libraries that include components
for this purpose.
I have seen other libraries as well, from companies like Otrix. My
favorite example is one of their JSF components, a tree control ...
but a tree control that is backed by a database of 6000 possible
entries. The component only downloads the portions of the data needed
for the currently expanded nodes, and uses asynchronous background
communication to grab more data when you expand new nodes.
>
> BaTien
> DBGROUPS
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale]: , , DialogController and Tiles
Posted by Duong BaTien <du...@gmail.com>.
Craig McClanahan wrote:
>On Apr 2, 2005 9:53 AM, NetSQL <ma...@friendvu.com> wrote:
>
>
>>Craig McClanahan wrote:
>>I'm quite intrigued by the Web Flow project in
>>
>>
>>>Swing's sandbox ...
>>>
>>>
>>Not Swing.
>>Spring or Don Brown's Ajax-Strtus sandbox I assume are both called "Flow".
>>
>>
>>
>
>Yes, I meant "Spring". They also recently released a milestone of this code.
>
>
Yes, i did take a quick look at Spring Web Flow. I am looking forward to
your integration under Shale. One small feature in the workflow that
seems quite useful is the persistence of each specified step so user
does not need to start from the beginning.
>
>
>>( I am glad it's in the back of your mind Freud. XUL, Flex, XAML, Ajax
>>(aka DHTML), JDNC all render on the client and improve performance by
>>offloading rendering from the server.)
>>
>>
>
>And there's even JSF components around that do this sort of thing too :-).
>
>
>
Craig:
Do you like to speculate and/or share the timing of this?
BaTien
DBGROUPS
>>At least not yet.
>>
>>.V
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>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: [Shale]: , , DialogController and Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On Apr 2, 2005 9:53 AM, NetSQL <ma...@friendvu.com> wrote:
> Craig McClanahan wrote:
> I'm quite intrigued by the Web Flow project in
> > Swing's sandbox ...
>
> Not Swing.
> Spring or Don Brown's Ajax-Strtus sandbox I assume are both called "Flow".
>
Yes, I meant "Spring". They also recently released a milestone of this code.
> ( I am glad it's in the back of your mind Freud. XUL, Flex, XAML, Ajax
> (aka DHTML), JDNC all render on the client and improve performance by
> offloading rendering from the server.)
And there's even JSF components around that do this sort of thing too :-).
>
> At least not yet.
>
> .V
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale]: , , DialogController and Tiles
Posted by NetSQL <ma...@friendVU.com>.
Craig McClanahan wrote:
I'm quite intrigued by the Web Flow project in
> Swing's sandbox ...
Not Swing.
Spring or Don Brown's Ajax-Strtus sandbox I assume are both called "Flow".
( I am glad it's in the back of your mind Freud. XUL, Flex, XAML, Ajax
(aka DHTML), JDNC all render on the client and improve performance by
offloading rendering from the server.)
At least not yet.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale]: , , DialogController and Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On Apr 1, 2005 2:11 PM, Duong BaTien <du...@gmail.com> wrote:
> Hello Craig:
>
> Well, this is Friday so we can take it easy on the debate between Struts
> and Jsf. This is about Struts-Shale, Jsf and Tiles.
>
> First, thank you for your contributions in CoR commons-chain and Shale.
> I had some time to re-visit shale and have successfully implemented
> shale as a servlet filter, its view controller with myfaces
> JspTilesViewHandlerImpl, and DialogController. Some questions:
>
> 1) The logon Dialog demonstrates an implementation of DialogController
> using hard-coded methods as entry points. Is there any thought of a
> generic Dialog bean whose actions and processes are assembled on-demand
> via CoR/IoC?
What would the method binding expression look like in this case?
Today, the last component of this expression is the name of the method
to be called, and you'd either have to maintain that or provide some
sort of custom method binding expression evaluator that did something
like creating a context and then firing off a chain.
It might just be simpler to compose a Context object, and fire off the
appropriate chain, yourself inside the event handling methods. With a
suitable helper function, each event handling method could be a simple
one liner.
On a parallel note, I'm quite intrigued by the Web Flow project in
Swing's sandbox, and am trying to carve out enough time to integrate
it into Shale. It is much more fleshed out than DialogController, and
includes nice concepts like nested subflows.
>
> 2) Association between view id and viewController is quite handy. I am
> able to associate each view id, assembled from complex tiles fragments,
> with a specialized viewController that pull part of the data from a
> dialogController. All tiles fragment use Jsf <f:subview>. Now moving to
> the shale <s:subview>, is it intended to replace jsf <f:subview> if more
> than 1 fragments requires viewController? I have not tested this case
> with myfaces tile viewHandler. I think i should wait for shale custom
> ViewHandler that works with tiles.
Yes, the intent is that <s:subview> would replace <f:subview> in order
to provide the lifecycle event calls for every fragment's
ViewController bean. If/when David gets done on extracting Tiles out
of Struts, and integrating it with Shale, we'll likely want a
component that does a combination of what <s:subview> and
<tiles:insert> do, so the developer won't have to use both.
The last time I tried (pre-1.0.9 though) the entire Shale use cases
example worked correctly with MyFaces as well as with the JSF RI. In
particular, there's a portion of the unit tests that verifies the
event calls occur in the correct order.
>
> 3) If <s:subview> is intended to replace <f:subview> to work with tiles,
> can it be done in such a way that each request needs to instantiate only
> 2 request-scope viewControllers for 2 fragments (portlet menu and its
> display fragments depending on which portlet user clicks)?
I suppose you could do that by specifying two subviews in the "outer"
page prepared by the portal server; but I want the ability to use
subviews *inside* a single portlet as well -- hence the desire to
support an arbitrary number of initialized ViewControllers per
request.
>
> BaTien
> DBGROUPS
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org