Hi BaTien,
thanks for using MyFaces. My comments are intermixed
> What shall i report following issue as a bug or a requested feature.
>
> Issue:
>
> Jsf + Tiles integration under myfaces works properly ONLY under the
> first level of tiles definition and layout. Myfaces seems to skip jsf
> phases after the first level.
>
> A patch to make jsf implementation work properly at least in all
> fragments of its generated html page will enable Jsf+Tiles as
> a portal
> rendering engine. Technically, tiles can be nested in any
> level, so Jsf
> + Tiles should be able to achieve this level of integration if the
Yes, it seams that, for now you could not use
a tile, that is refered by a tile. Do you
got any more info on that?
> 2.1) <h:commandButton> and <h:commandLink> are
> identically rendered
> (by looking at the page source - obviously with different
> component Ids)
> under the fragments of the page layout and fragments inserted
> by tiles.
> However, a click on <h:commandButton> and <h:commandLink> in the
> fragment inserted by tiles displays the same page. This means command
> actionListenner and action are skipped.
Have you tried navigation-rules without <from-view-id/> element:
<navigation-rule>
<navigation-case>
<from-outcome>myOutcome</from-outcome>
<to-view-id>/yetAnotherJSP.jsp</to-view-id>
</navigation-case>
</navigation-rule>
Since your page is composed via Tiles you may use
*global* navigation rulez. Those rules are not
specific to a special viewId (eg. myNavigationSite.jsp)
> 2.2) I put a simple onclick Javascript to check if password and
> confirmPassord identical. The onclick Javascript is executed,
> but when
> submitted the command action is ignored. This indicates that
> jsf phases
> are skipped.
Perhaps the same issue with this?
Btw. have you tried <x:validateEqual/> of MyFaces?
This enables you to confim passwords eg.
(if you don't want JavaScript ;-))
> 2.3) <h:outputLink> dispatches to correct page under both
> types of
> fragments (layout fragment and tiles inserted fragment). This working
yes, that isn't using faces-config.xml for navigation
> case makes me think a temporary workaround may be to use
> <h:outputLink>
> only in the portlet inserted tile fragment and any page that required
> jsf actionListener, action will have a complete portal page
> layout cut
> and paste into it while waiting for a real solution of
> properly rendring
> Jsf components under tiles. This temporary solution goes against the
> reason why tiles is used in the first place.
Yes, this goes against using Tiles
> 3) Using the temporary solution as explained in 2.3, i
> experiment with
> dynamically generated portal tabs. The servlet dispatcher
> consistently
> throw ClassCastException for the last tab, while the same thing under
> 2.1 and 2.2 (i.e. jsf action and actionListener are NOT
> properly picked
> up) is stable and work properly. The root cause may then be
> the way how
> jsf is implemented. I hope this can be quickly patched and
> let us enjoy
> the fruit of Jsf + Tiles.
Could you please provide abit more of stracktrace
for this case?
Thanks,
Matthias
> PS: If you are too busy, you can explain how jsf
> implementation is done
> and possible problems under tiles, and direct me to possible
> sources to
> resolve the issue.
>
> Thanks
>
> BaTien
> DBGROUPS
>
>
>
> BaTien Duong wrote:
>
> > Hello:
> >
> > Using myfaces-1.0.7, i was able create a complete dynamic
> portal page
> > and tiles insertions of the display and portlet fragments. Each jsf
> > page is a custom portal tab form.<h:commandButton> behaves normally
> > within a portal page and can pick up correct action for a new page
> > with new tiles fragments. However, within a fragment inserted by
> > tiles, the <h:commandButton> does not pick up the command action.
> >
> > Investigations:
> >
> > (1) I tried both with and without the parent form and use /
> or NOT use
> > parent form generation from myfaces. Results are the same.
> >
> > (2) Looking at the generated html from myfaces, i saw the generated
> > codes onclick for the <h:commandButton> that clears the old action
> > form and supposely leads to the next navigation action. But this is
> > not the case for the <h:commandButton> inside an inserted
> tiles fragment.
> >
> > Possible solutions:
> >
> > (1) Is there any readily solution and/or quick fix for the above
> > issue? Even some direction to fix from source codes may help.
> >
> > (2) One possible solution may be to write a custom onclick attribute
> > for each <h:commandButton> within a tiles insertion, since myfaces
> > will concatenate the custom onclick attribute with its generated
> > javascript clear() function.
> >
> > Sory to post this in both dev and user lists.
> >
> > Thanks.
> >
> > BaTien
> > DBGROUPS
> >
> >
>
