You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Mind Bridge <mi...@yahoo.com> on 2005/05/02 15:43:02 UTC
Re: For
Hi,
I have put up the documentation of the updated For component here:
http://www.t-deli.com/new-doc/Base.For.html
Some examples:
<span jwcid="@For" source="...">
...
</span>
The very minimum. It is exactly the same as Foreach. 'value' and 'index'
bindings can be added as required. The rendered HTML element will be exactly
the same as the template (span in this case) unless it is overridden, of
course.
This example also automatically behaves like ListEdit if it is placed in a
form, but the values in 'source' must be squeezable.
<span jwcid="@For" source="..." formless="true">
...
</span>
Same as above, but the component will always behave like a Foreach, even
within a form.
And some advanced examples:
<span jwcid="@For" source="ognl: people" primaryKeyExpression="id'
defaultValue="ognl: new PersonData()">
...
</span>
This is an example of using For in a form, but without having squeezable
values in 'source'. In this example, the values are of type PersonData, and
getId() returns the primary key of that object. No Java code is required.
Note that 'primaryKeyExpression' and 'defaultValue' will be ignored if the
For is not located in a form.
<span jwcid="@For" source="ognl: visiblePeople" fullSource="ognl:
allPeople" primaryKeyExpression="id' defaultValue="ognl: new PersonData()">
...
</span>
Same as above, but here only a part of the people are displayed. Since that
part may change between requests, all of the personData objects are provided
in the 'fullSource' parameter to enable the reverse 'primary key -> object'
lookup.
If 'fullSource' is not provided, the component falls back to using 'source'.
<span jwcid="@For" source="ognl: people" convertor="ognl: convertor">
...
</span>
In this example an IPrimaryKeyConvertor is used to convert values to primary
keys and back.
It is a more flexible approach, but it typically requires some Java code
hence it is not that easy.
<span jwcid="@For" source="ognl: people" convertor="ognl: convertor"
primaryKeys="ognl: primaryKeys">
...
</span>
Here setPrimaryKeys() is invoked before the iterations begin and that gives
an opportunity to create and return a very efficient primary key convertor
in getConvertor().
Comments?
-mb
----- Original Message -----
From: "Mind Bridge" <mi...@yahoo.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Saturday, April 30, 2005 11:03 AM
Subject: For
> Hi,
>
> I am in the process of making changes in the CVS and one of the things
that
> I am adding are the If, Else, and For components (as on www.t-deli.com).
>
> All of these combine existing components, but while If and Else are fairly
> non-contentious, For is a bit problematic.
> The reasons are following:
>
> - IPrimaryKeyConvertor instead of ListEditMap
> Both For and ListEdit provide mechanisms to override the default
> 'squeezing'. The difference is that IPrimaryKeyConvertor is a relatively
> simple interface providing getPrimaryKey/getValue, while ListEditMap is a
> full-fledged map. I am assuming in the discussion below that the objects
are
> big enough or simply non-serializable and render squeezing impractical.
>
> If I am not mistaken, ListEditMap needs to be initialized with all
relevant
> objects in order to work well. This is often necessary anyway as the data
> comes from a database and it is often (but not always) better to load the
> data with just one query, rather than have a query for each primary key
> requested.
>
> IPrimaryKeyConvertor instead allows you to load only specific primary keys
> rather than the full collection. It can however be backed by a Map with
the
> full collection, ant it will behave like ListEditMap. The choice is up to
> the developer. In addition, a number of people have indicated that
> IPrimaryKeyConvertor is simpler to understand as well. Unfortunately,
there
> isn't a standard implementation for the latter because of the possible
> variations, but perhaps this needs to be rectified.
>
> In short, are there any comments/objections to using IPrimaryKeyConvertor
> for For?
>
>
> - Simplified primary key conversion
> Apparently, even IPrimaryKeyConvertor is too complex for some people and a
> simpler mechanism should be provided. In addition, a lot of people do not
> implement equals() and hashCode() on their data objects and/or use ==
rather
> than equals() and then wonder why things are not working.
>
> Here is a possible approach: The getPrimaryKey() portion of the interface
> can be easily implemented in a simpler way using an OGNL parameter that
> extracts the primary key from the iterated object (it will by just 'id' in
> the general case). The getValue() portion is a bit tricky, however, as it
is
> unclear where to get the full values from.
>
> One way is to take the list provided in 'source', the provided OGNL
> expression can be used to extract the primary keys and a map 'primary
key ->
> value' can be built. It will then be used to perform getValue(). This will
> work in most cases, and will even take care of the == problem above. The
> problem is that it is entirely possible for a value with that primary key
to
> exist, but not to be in source -- e.g. if the rendered part of the list
has
> shifted between requests. Depending on the use case, that may be
> problematic.
>
> My gut feeling is to have both the OGNL primary key expression and
> IPrimaryKeyConvertor. Which of the two mechanisms the developer will
choose
> is up to him, but the possible dangers need to explained in the
> documentation. (of course, the third one -- squeezing is probably best if
it
> is possible)
>
> Two more questions:
> - About rewind: Is there a need for people to be able to get the list of
> primary keys before the iteration begins? (probably via a binding)
> Some people have expressed such a desire in other contexts, and it makes a
> certain sense as it will allow you to know exactly what values should be
> loaded in your map.
>
> - Is there a need to have an ActionListener in For? If I understand
> correctly, it was provided in ListEdit mostly to support ListEditMap.
>
> Best regards,
> -mb
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Javascript generation - correction
Posted by Karthik Abram <ka...@neovera.com>.
Can you change the Tapestry 4.x javascript emitter to emit
<script type="text/javascript">
blah
</script>
instead of
<script language="javascript">
blah
</script>
The language attribute is deprecated..
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: For
Posted by Pablo Lalloni <pl...@afip.gov.ar>.
El Lun 02 May 2005 17:27, Harish Krishnaswamy escribió:
> > > I'm troubled by the parameter named "formless"; it seems like their
> > > could
> >
> > be
> >
> > > a better name, I just can't think of what it would be.
> >
> > I agree, I am troubled by it as well, and I cannot come up with a better
> > name either. Any ideas are very welcome.
> > One more such issue: I think 'primaryKeyExpression' is way too long.
> > Should it be 'PKExpression' instead? Any alternatives?
>
> How about "mutableBody" for formless? I think PrimaryKeyExpression is
> just fine, I particularly don't like PKExpression.
Maybe just "keyExpression", since it does not need to be "primary" at all, it
just needs to be "unique".
Also "expression" might be redundant, making options from "key" and
"uniqueKey" valid.
I think I would prefer just "key".
--
Pablo
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: For
Posted by Nathan Kopp <nk...@mailshell.com>.
"Jamie Orchard-Hays" <ja...@dang.com> wrote...
> form="true" and form="false"
In the "For" component, doesn't the "formless" property mean, "Even if
rendered in a form, don't render the hidden fields." If so, then I think
that something like staleFormProtection="true" (default) and
staleFormProtection="false" (or something with this same meaning) would make
sense.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: For
Posted by Jamie Orchard-Hays <ja...@dang.com>.
form="true" and form="false"
On May 2, 2005, at 4:08 PM, Mind Bridge wrote:
>> I'm troubled by the parameter named "formless"; it seems like their
>> could
> be
>> a better name, I just can't think of what it would be.
>
> I agree, I am troubled by it as well, and I cannot come up with a
> better
> name either. Any ideas are very welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: For
Posted by Harish Krishnaswamy <ha...@gmail.com>.
Forget the previous suggestion, how about "volatile"? You basically
want to record them in the form only if the source is volatile.
On 5/2/05, Harish Krishnaswamy <ha...@gmail.com> wrote:
> > > I'm troubled by the parameter named "formless"; it seems like their could
> > be
> > > a better name, I just can't think of what it would be.
> >
> > I agree, I am troubled by it as well, and I cannot come up with a better
> > name either. Any ideas are very welcome.
> > One more such issue: I think 'primaryKeyExpression' is way too long. Should
> > it be 'PKExpression' instead? Any alternatives?
>
> How about "mutableBody" for formless? I think PrimaryKeyExpression is
> just fine, I particularly don't like PKExpression.
>
> -Harish
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: For
Posted by Harish Krishnaswamy <ha...@gmail.com>.
> > I'm troubled by the parameter named "formless"; it seems like their could
> be
> > a better name, I just can't think of what it would be.
>
> I agree, I am troubled by it as well, and I cannot come up with a better
> name either. Any ideas are very welcome.
> One more such issue: I think 'primaryKeyExpression' is way too long. Should
> it be 'PKExpression' instead? Any alternatives?
How about "mutableBody" for formless? I think PrimaryKeyExpression is
just fine, I particularly don't like PKExpression.
-Harish
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: For
Posted by Mind Bridge <mi...@yahoo.com>.
Hi Howard,
Thank you for your comments.
To answer your questions:
> I didn't immediately see what the recovery is for the object no longer in
> database.
The parameter 'defaultValue' should serve that purpose. If there is no value
for the given primary key, then 'defaultValue' is used instead. It is
essentially a place-holder.
I will think about exceptions, the form interruption, and a listener in
general, and will get back to you on this.
> I think it would be good if the IPrimaryKeyConverter interface had some
kind
> of void preloadObjects(Object[] primaryKeys) method, that would allow the
> PKC to efficiently get all the objects it will likely need, rather than
have
> to get them piecemeal ... that is, a way to optimize transactions and
round
> trips.
After some deliberation, I think it is a good idea to add this to the
interface. If the implementation is not interested, it can always leave it
empty.
The reason I did not place that function in the interface initially was to
allow implementations without it and hence simplify what people need to do.
The preloading was to be performed in the specific implementation. Also,
'For' now has an out parameter 'primaryKeys'. Nevertheless, it is good to
have everything in one place.
> I hate to bloat the framework, but if you have unit tests for these (you
DO,
> don't you?) then I think they belong directly in the framework, and we
> should come up with an end-of-life policy for the other components
> (Conditional, Foreach, ListEdit).
Actually I do not have unit tests at the moment (testing the stuff in an
app), which is the main reason why I have not checked the components in yet
:). But when check them in, I can guarantee that there will be unit tests
with them.
> I'm troubled by the parameter named "formless"; it seems like their could
be
> a better name, I just can't think of what it would be.
I agree, I am troubled by it as well, and I cannot come up with a better
name either. Any ideas are very welcome.
One more such issue: I think 'primaryKeyExpression' is way too long. Should
it be 'PKExpression' instead? Any alternatives?
> Finally, take a look at the default-binding element of <parameter> (a
recent
> add).
Good point, I will set the relevant defaults.
> Despite the much greater complexity of this component (relative to
Foreach)
> I think this is a step in the right directon; it is shorter and simpler to
> use initially, since it is use-what-you-need.
To be frank, I am uneasy with the complexity myself given how basic the
component is, but as you say, the provided functionality appears to be much
needed unfortunately...
Best regards,
-mb
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Monday, May 02, 2005 7:04 PM
Subject: Re: For
This all looks good to me, deprecating Foreach and ListEdit in favor of For
is a good thing.
I didn't immediately see what the recovery is for the object no longer in
database. Using ListEditMap you have the flexibily to abort the form, or to
supply a placeholder object. I'm hoping it will generally be possible to use
an off-the-shelf PKC as a <bean> and deal with these issues via
configuration (such as injecting a listener method into the bean).
I think it would be good if the IPrimaryKeyConverter interface had some kind
of void preloadObjects(Object[] primaryKeys) method, that would allow the
PKC to efficiently get all the objects it will likely need, rather than have
to get them piecemeal ... that is, a way to optimize transactions and round
trips.
I hate to bloat the framework, but if you have unit tests for these (you DO,
don't you?) then I think they belong directly in the framework, and we
should come up with an end-of-life policy for the other components
(Conditional, Foreach, ListEdit).
I'm troubled by the parameter named "formless"; it seems like their could be
a better name, I just can't think of what it would be.
Finally, take a look at the default-binding element of <parameter> (a recent
add). It allows you to omit prefixes and still have the values interpretted
as OGNL expressions, or what have you.
Despite the much greater complexity of this component (relative to Foreach)
I think this is a step in the right directon; it is shorter and simpler to
use initially, since it is use-what-you-need. In addition, from the
consistency point of view, not having to think about which component to use
inside a form is good (thought the user will have to decide which additional
parameters to use to make it work optimally inside a form).
On 5/2/05, Mind Bridge <mi...@yahoo.com> wrote:
>
> Hi,
>
> I have put up the documentation of the updated For component here:
>
> http://www.t-deli.com/new-doc/Base.For.html
>
> Some examples:
>
> <span jwcid="@For" source="...">
> ...
> </span>
>
> The very minimum. It is exactly the same as Foreach. 'value' and 'index'
> bindings can be added as required. The rendered HTML element will be
> exactly
> the same as the template (span in this case) unless it is overridden, of
> course.
>
> This example also automatically behaves like ListEdit if it is placed in a
> form, but the values in 'source' must be squeezable.
>
> <span jwcid="@For" source="..." formless="true">
> ...
> </span>
>
> Same as above, but the component will always behave like a Foreach, even
> within a form.
>
> And some advanced examples:
>
> <span jwcid="@For" source="ognl: people" primaryKeyExpression="id'
> defaultValue="ognl: new PersonData()">
> ...
> </span>
>
> This is an example of using For in a form, but without having squeezable
> values in 'source'. In this example, the values are of type PersonData,
> and
> getId() returns the primary key of that object. No Java code is required.
>
> Note that 'primaryKeyExpression' and 'defaultValue' will be ignored if the
> For is not located in a form.
>
> <span jwcid="@For" source="ognl: visiblePeople" fullSource="ognl:
> allPeople" primaryKeyExpression="id' defaultValue="ognl: new
> PersonData()">
> ...
> </span>
>
> Same as above, but here only a part of the people are displayed. Since
> that
> part may change between requests, all of the personData objects are
> provided
> in the 'fullSource' parameter to enable the reverse 'primary key ->
> object'
> lookup.
>
> If 'fullSource' is not provided, the component falls back to using
> 'source'.
>
> <span jwcid="@For" source="ognl: people" convertor="ognl: convertor">
> ...
> </span>
>
> In this example an IPrimaryKeyConvertor is used to convert values to
> primary
> keys and back.
> It is a more flexible approach, but it typically requires some Java code
> hence it is not that easy.
>
> <span jwcid="@For" source="ognl: people" convertor="ognl: convertor"
> primaryKeys="ognl: primaryKeys">
> ...
> </span>
>
> Here setPrimaryKeys() is invoked before the iterations begin and that
> gives
> an opportunity to create and return a very efficient primary key convertor
> in getConvertor().
>
> Comments?
>
> -mb
>
> ----- Original Message -----
> From: "Mind Bridge" <mi...@yahoo.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Saturday, April 30, 2005 11:03 AM
> Subject: For
>
> > Hi,
> >
> > I am in the process of making changes in the CVS and one of the things
> that
> > I am adding are the If, Else, and For components (as on
www.t-deli.com<http://www.t-deli.com>
> ).
> >
> > All of these combine existing components, but while If and Else are
> fairly
> > non-contentious, For is a bit problematic.
> > The reasons are following:
> >
> > - IPrimaryKeyConvertor instead of ListEditMap
> > Both For and ListEdit provide mechanisms to override the default
> > 'squeezing'. The difference is that IPrimaryKeyConvertor is a relatively
> > simple interface providing getPrimaryKey/getValue, while ListEditMap is
> a
> > full-fledged map. I am assuming in the discussion below that the objects
> are
> > big enough or simply non-serializable and render squeezing impractical.
> >
> > If I am not mistaken, ListEditMap needs to be initialized with all
> relevant
> > objects in order to work well. This is often necessary anyway as the
> data
> > comes from a database and it is often (but not always) better to load
> the
> > data with just one query, rather than have a query for each primary key
> > requested.
> >
> > IPrimaryKeyConvertor instead allows you to load only specific primary
> keys
> > rather than the full collection. It can however be backed by a Map with
> the
> > full collection, ant it will behave like ListEditMap. The choice is up
> to
> > the developer. In addition, a number of people have indicated that
> > IPrimaryKeyConvertor is simpler to understand as well. Unfortunately,
> there
> > isn't a standard implementation for the latter because of the possible
> > variations, but perhaps this needs to be rectified.
> >
> > In short, are there any comments/objections to using
> IPrimaryKeyConvertor
> > for For?
> >
> >
> > - Simplified primary key conversion
> > Apparently, even IPrimaryKeyConvertor is too complex for some people and
> a
> > simpler mechanism should be provided. In addition, a lot of people do
> not
> > implement equals() and hashCode() on their data objects and/or use ==
> rather
> > than equals() and then wonder why things are not working.
> >
> > Here is a possible approach: The getPrimaryKey() portion of the
> interface
> > can be easily implemented in a simpler way using an OGNL parameter that
> > extracts the primary key from the iterated object (it will by just 'id'
> in
> > the general case). The getValue() portion is a bit tricky, however, as
> it
> is
> > unclear where to get the full values from.
> >
> > One way is to take the list provided in 'source', the provided OGNL
> > expression can be used to extract the primary keys and a map 'primary
> key ->
> > value' can be built. It will then be used to perform getValue(). This
> will
> > work in most cases, and will even take care of the == problem above. The
> > problem is that it is entirely possible for a value with that primary
> key
> to
> > exist, but not to be in source -- e.g. if the rendered part of the list
> has
> > shifted between requests. Depending on the use case, that may be
> > problematic.
> >
> > My gut feeling is to have both the OGNL primary key expression and
> > IPrimaryKeyConvertor. Which of the two mechanisms the developer will
> choose
> > is up to him, but the possible dangers need to explained in the
> > documentation. (of course, the third one -- squeezing is probably best
> if
> it
> > is possible)
> >
> > Two more questions:
> > - About rewind: Is there a need for people to be able to get the list of
> > primary keys before the iteration begins? (probably via a binding)
> > Some people have expressed such a desire in other contexts, and it makes
> a
> > certain sense as it will allow you to know exactly what values should be
> > loaded in your map.
> >
> > - Is there a need to have an ActionListener in For? If I understand
> > correctly, it was provided in ListEdit mostly to support ListEditMap.
> >
> > Best regards,
> > -mb
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: For
Posted by Howard Lewis Ship <hl...@gmail.com>.
This all looks good to me, deprecating Foreach and ListEdit in favor of For
is a good thing.
I didn't immediately see what the recovery is for the object no longer in
database. Using ListEditMap you have the flexibily to abort the form, or to
supply a placeholder object. I'm hoping it will generally be possible to use
an off-the-shelf PKC as a <bean> and deal with these issues via
configuration (such as injecting a listener method into the bean).
I think it would be good if the IPrimaryKeyConverter interface had some kind
of void preloadObjects(Object[] primaryKeys) method, that would allow the
PKC to efficiently get all the objects it will likely need, rather than have
to get them piecemeal ... that is, a way to optimize transactions and round
trips.
I hate to bloat the framework, but if you have unit tests for these (you DO,
don't you?) then I think they belong directly in the framework, and we
should come up with an end-of-life policy for the other components
(Conditional, Foreach, ListEdit).
I'm troubled by the parameter named "formless"; it seems like their could be
a better name, I just can't think of what it would be.
Finally, take a look at the default-binding element of <parameter> (a recent
add). It allows you to omit prefixes and still have the values interpretted
as OGNL expressions, or what have you.
Despite the much greater complexity of this component (relative to Foreach)
I think this is a step in the right directon; it is shorter and simpler to
use initially, since it is use-what-you-need. In addition, from the
consistency point of view, not having to think about which component to use
inside a form is good (thought the user will have to decide which additional
parameters to use to make it work optimally inside a form).
On 5/2/05, Mind Bridge <mi...@yahoo.com> wrote:
>
> Hi,
>
> I have put up the documentation of the updated For component here:
>
> http://www.t-deli.com/new-doc/Base.For.html
>
> Some examples:
>
> <span jwcid="@For" source="...">
> ...
> </span>
>
> The very minimum. It is exactly the same as Foreach. 'value' and 'index'
> bindings can be added as required. The rendered HTML element will be
> exactly
> the same as the template (span in this case) unless it is overridden, of
> course.
>
> This example also automatically behaves like ListEdit if it is placed in a
> form, but the values in 'source' must be squeezable.
>
> <span jwcid="@For" source="..." formless="true">
> ...
> </span>
>
> Same as above, but the component will always behave like a Foreach, even
> within a form.
>
> And some advanced examples:
>
> <span jwcid="@For" source="ognl: people" primaryKeyExpression="id'
> defaultValue="ognl: new PersonData()">
> ...
> </span>
>
> This is an example of using For in a form, but without having squeezable
> values in 'source'. In this example, the values are of type PersonData,
> and
> getId() returns the primary key of that object. No Java code is required.
>
> Note that 'primaryKeyExpression' and 'defaultValue' will be ignored if the
> For is not located in a form.
>
> <span jwcid="@For" source="ognl: visiblePeople" fullSource="ognl:
> allPeople" primaryKeyExpression="id' defaultValue="ognl: new
> PersonData()">
> ...
> </span>
>
> Same as above, but here only a part of the people are displayed. Since
> that
> part may change between requests, all of the personData objects are
> provided
> in the 'fullSource' parameter to enable the reverse 'primary key ->
> object'
> lookup.
>
> If 'fullSource' is not provided, the component falls back to using
> 'source'.
>
> <span jwcid="@For" source="ognl: people" convertor="ognl: convertor">
> ...
> </span>
>
> In this example an IPrimaryKeyConvertor is used to convert values to
> primary
> keys and back.
> It is a more flexible approach, but it typically requires some Java code
> hence it is not that easy.
>
> <span jwcid="@For" source="ognl: people" convertor="ognl: convertor"
> primaryKeys="ognl: primaryKeys">
> ...
> </span>
>
> Here setPrimaryKeys() is invoked before the iterations begin and that
> gives
> an opportunity to create and return a very efficient primary key convertor
> in getConvertor().
>
> Comments?
>
> -mb
>
> ----- Original Message -----
> From: "Mind Bridge" <mi...@yahoo.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Saturday, April 30, 2005 11:03 AM
> Subject: For
>
> > Hi,
> >
> > I am in the process of making changes in the CVS and one of the things
> that
> > I am adding are the If, Else, and For components (as on www.t-deli.com<http://www.t-deli.com>
> ).
> >
> > All of these combine existing components, but while If and Else are
> fairly
> > non-contentious, For is a bit problematic.
> > The reasons are following:
> >
> > - IPrimaryKeyConvertor instead of ListEditMap
> > Both For and ListEdit provide mechanisms to override the default
> > 'squeezing'. The difference is that IPrimaryKeyConvertor is a relatively
> > simple interface providing getPrimaryKey/getValue, while ListEditMap is
> a
> > full-fledged map. I am assuming in the discussion below that the objects
> are
> > big enough or simply non-serializable and render squeezing impractical.
> >
> > If I am not mistaken, ListEditMap needs to be initialized with all
> relevant
> > objects in order to work well. This is often necessary anyway as the
> data
> > comes from a database and it is often (but not always) better to load
> the
> > data with just one query, rather than have a query for each primary key
> > requested.
> >
> > IPrimaryKeyConvertor instead allows you to load only specific primary
> keys
> > rather than the full collection. It can however be backed by a Map with
> the
> > full collection, ant it will behave like ListEditMap. The choice is up
> to
> > the developer. In addition, a number of people have indicated that
> > IPrimaryKeyConvertor is simpler to understand as well. Unfortunately,
> there
> > isn't a standard implementation for the latter because of the possible
> > variations, but perhaps this needs to be rectified.
> >
> > In short, are there any comments/objections to using
> IPrimaryKeyConvertor
> > for For?
> >
> >
> > - Simplified primary key conversion
> > Apparently, even IPrimaryKeyConvertor is too complex for some people and
> a
> > simpler mechanism should be provided. In addition, a lot of people do
> not
> > implement equals() and hashCode() on their data objects and/or use ==
> rather
> > than equals() and then wonder why things are not working.
> >
> > Here is a possible approach: The getPrimaryKey() portion of the
> interface
> > can be easily implemented in a simpler way using an OGNL parameter that
> > extracts the primary key from the iterated object (it will by just 'id'
> in
> > the general case). The getValue() portion is a bit tricky, however, as
> it
> is
> > unclear where to get the full values from.
> >
> > One way is to take the list provided in 'source', the provided OGNL
> > expression can be used to extract the primary keys and a map 'primary
> key ->
> > value' can be built. It will then be used to perform getValue(). This
> will
> > work in most cases, and will even take care of the == problem above. The
> > problem is that it is entirely possible for a value with that primary
> key
> to
> > exist, but not to be in source -- e.g. if the rendered part of the list
> has
> > shifted between requests. Depending on the use case, that may be
> > problematic.
> >
> > My gut feeling is to have both the OGNL primary key expression and
> > IPrimaryKeyConvertor. Which of the two mechanisms the developer will
> choose
> > is up to him, but the possible dangers need to explained in the
> > documentation. (of course, the third one -- squeezing is probably best
> if
> it
> > is possible)
> >
> > Two more questions:
> > - About rewind: Is there a need for people to be able to get the list of
> > primary keys before the iteration begins? (probably via a binding)
> > Some people have expressed such a desire in other contexts, and it makes
> a
> > certain sense as it will allow you to know exactly what values should be
> > loaded in your map.
> >
> > - Is there a need to have an ActionListener in For? If I understand
> > correctly, it was provided in ListEdit mostly to support ListEditMap.
> >
> > Best regards,
> > -mb
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com