I learned your points and they are convincing under certain conditions.
But I could not reach a conclusion for myself to drop the "name"
attribute completely, because of some additional concerns.
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 10:36 AM
Subject: Re: [Forward-Looking] Struts and JavaServer Faces
>
>
> 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.
>
Agree with this one. Struts should implement modelReference to
cover standard requirements.
> * 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.
>
Not clear with this one. The "name" attribute in a general custom
action refers to a JSP scope attribute name, the "property" attribute
refers to the named bean's property. By definition, they do not have
direct relationship with user interfaces. Of cause, their combination can
produce whatever modelReference can do when used in JSF contexts.
But they are not necessary limited only to user interfaces.
> * 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.
It is my understanding that modelReference is a compound
while the name/property/scope could be the indivisible components of
such compound. Some use cases are better served by compounds and
some are better served by individual components.
For example, some applications allow people to input city, state, zip code
in single field, while others may allow people to input city, state, and
zip code into three different fields because they want to control what
cities or states people could select.
The major concern I have now is that we do have use cases that need to
control each individual component. We do not want people to write
a free style expression for certaion custom actions.
The second concern is that if a bean CustomerAccount is used
by modelReference 50 times in a JSP page, then the EL engine has to
evaluate ${CustomerAccount.p1}, ${CustomerAccount.p2}, ...
${CustomerAccount.p50}. Eventhough the EL engine can cache what
it evaluates before, there are a lot of redundant computing tasks
for the EL to extract out the 'CustomerAccount'. Maybe I am missing
something here, but I am wondering how this is better handled. My
rational goes like this: The parent compnent (e.g. FormTag) stores
the bean by a "name" attribute, and all children will keep only
"property" attributes and they will use the named bean from their
parent along with the kept property when rendering.
Regardless what is the best way to handle it, I think there are
rationals for the "name" and "property" attributes in the future.
JSTL is 1.0, and JSF is less than 1.0, there is a long way for
them to evolve to a mature point when comparing with JDBC
evolving from 1.0 to 3.0.
The closest thing in JSTL 1.0 to the "name" attribute is the "var"
attribute, which is used to export information, while the
"name" is used to import information. This might give us a clue
how the future spec will evolve ... (looks like we are missing
a standard way to import information)
Comments or suggestions are welcom to help me to address those
concerns in a better way. I know it is not hard to support both
conventions and hope struts could do it or at least make it easy
to add general attributes by some design patterns.
There is another difficulty in the current html taglib. When I tried
to use a different EL engine, I have to subclass all related action
classes and copy everything else. I hope new version could define
one type of EL engine per module at design time, and one
instance of EL egnine per module at run time. So we can easily
plugin custom evaluation policy. This is a rough idea, hope someone
could provide some design patterns for it too.
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
Jing
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
