On Wed, 18 Sep 2002, Jing Zhou wrote:
> >[snip]
> > * Transition one page at a time to use the new tag libraries,
> > making an appropriate modification to the <forward> elements
> > for your pages (the URL needs to change to meet Faces requirements).
> >
>
> Could you provide a simple example to show how <forward>
> should be modified? Will it require to change ActionForward class itself,
> or just the path attribute need to be changed?
>
No software change at all required -- only a change in the path attribute
in struts-config.xml. For example, from:
<forward name="registration" path="/registration.jsp"/>
to
<forward name="registration" path="/faces/registration.jsp"/>
> I noticed that some *actions* in faces are for component's state
> changes,
> so there will be no populating, validating, and action things for them.
> Are we going to use the ActionForward class to go to the same component
> with changed states, is that correct? (For example, a tab pane is changed
> from visible tab item 0 to visible tab item 1)
>
The integration library will still offer full support for form beans and
auto-population, with calls to reset() and validate() at the right times,
and so on. This is primarily to support existing code. New apps will
want to make a choice between using form beans (in the traditional Struts
fashion) and just using Faces components (with their per-component
pluggable validators) directly.
> [snip]
> One thing we had discussed sometime ago was about split name/property
> v.s. merged name/property. It is understandable to attempt to have a merged
> name/property so that we could map it to faces modelReference. I feel I need
> to do lobby works to reserve the split name/property version, if necessary.
>
> The split version of name/property provides a better mapping and more
> functions than merged modelReference:
> 1) "name" is mapped to JSP attribute name in the four JSP scopes;
> 2) "property" is mapped to JavaBean's property;
> 3) "name" + "." + "property" is mapped to Faces modelReference;
> 4) "name" and "property" can be evaluated by an EL engine independently;
> 5) "name" and "property" completely hide HTML's name attribute;
>
> If one considers the RequestUtils.lookup() as a mini-evaluator, 4) give us
> a so called two-phase evaluations. While the merged modelReference can
> only give us one-phase evaluation and thus we lost the function 4) So,
> the "name" and "property" are well defined and well seperated in the
> mapping, they shouldn't be deprecated ... I saw David's struts-el
> contribution,
> he's done a good job, we still have the split version. But I am not sure
> if your Struts/JSF integration will keep it or not. I expect the integration
> will make Struts *stand on* JSF and bigger than JSF.
>
For making JSF do something like this, I suspect this one is going to be a
hard sell to the EG, but you can try by submitting the feedback to
[EMAIL PROTECTED]
The reasons I think this way are as follows:
* The split syntax is totally incompatible with variable references
in JSTL 1.0 and JSP 2.0, which don't support it. It would not be
appropriate for JSF to be gratuitously incompatible with this
standard.
* The split syntax is too restrictive, because it assumes the shape
of the graph of model beans matches the shape of the graph of
user interface components. This has proven to be troublesome
to many Struts users already.
* The actual data that a model reference points at is ambiguous
because it is sensitive to the location of a component in a page.
This makes life much harder for tools, which will prefer to use
absolute model reference expressions during development.
For making Struts use supersets of the standard EL syntax (along the lines
you are describing), that sounds like a bad strategy to me -- we really
really want people already familiar with standard EL expression syntax to
be able to use Struts and know what to expect. Thus, I think we need to
make the struts-el library conform a little more closely, now that we know
what the syntax requirements of model reference expressions are going to
be.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
