Le May 27, 2005 � 11:50 AM, Craig McClanahan a �crit :
On 5/27/05, Duong BaTien <[EMAIL PROTECTED]> wrote:
Re post from myfaces to appropriate list.
http://wiki.apache.org/struts/StrutsShale
The javadoc actually contains quite a bit of explanation. The
usescases are also built nightly and they are an excellent
example of
how the new dialog stuff works.
I posted a blog entry on Shale Web Flow the other day. See /http://
jroller.com/page/dgeary
david
Hello David:
I manage to get back to Shale Dialog and read your blog on Shale Web
Flow. Craig just comes back from vacation. Welcome back ;-). So i
decide to fire up some of the questions. Hope you two may save me
time
to dig around.
1) You said Shale loads the state's view using the supplied viewId
(which i am able to replace my previous implementation under
DialogController to the new Dialog - it is great to see similar
structure like web flow: flow and sub-flow), and soon we will be
able to
supply a tile based on your work. I wonder what is its implication?
I'll let David speak to where Tiles is.
If you use Tiles with Shale dialogs, your dialog views are most
likely JSP pages that simply load a tile. After we get Tiles
integrated with Shale, you'll be able to specify that tile directly.
david
2) If i recalled in the previous version of DialogController, Craig
said "soon" we will be able to have different instances of
DialogController, controlling different fragments (tiles) in the same
page, so the deprecated DialogController is similar to Tiles
controller
but it can last more than a request. I look at the new Dialog
Status and
StatusImpl, there is only 1 property "data". Hence, at any point you
can only associate 1 state to the {dialog.data}. I wonder how
different
work flows can be independently associated to different fragments
in the
same page? Specifically, i am thinking different work flows are
associated with different applications; each application occupies
1 or 2
fragments of a portal page.
That use case is going to require some additional machinery that uses
different dialog instances (i.e. different session scope Status
instances) for the various simultaneously executing dialogs. It will
also require the framework to maintain an association with each
fragment and the corresponding status instance for the owning dialog.
Hmm ... between the dynamic subview stuff/Tiles/Clay we can probably
deal with the components side of that fairly gracefully; the
interesting bit will be the server side state. Gotta think a bit more
on that one.
3) I have a project with dead line in the next 5 months. Will the new
tiles be able to handle i18n for English and French as the original
version or i have to create a complete mirror sites?
Do you need more than the support that JSF already provides for i18n?
Things like:
<f:loadBundle var="messages"
basename="com.mycompany.mypackage.Bundle"/>
...
<h:outputText value="#{messages['prompt.username']}"/>
...
<h:commandButton ... value="#{messages['label.save']}"/>
Thanks.
BaTien
DBGROUPS
Craig
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
