This thread is a little stale, apologies, but it's been a crazy
month, and
this topic deserves more consideration.
As a long time user of Tapestry (since T3) and an early adopter of
T5 (since
~T5.0.0), my experience with type coercion has been love/hate. But
mostly
hate.
When there was only TypeCoercer to think about, things were much
simpler.
There was only one possible path of type coercion for the entire
system,
and, importantly, things ... just... worked.
With the introduction of:
Translator
ValueEncoder
PrimaryKeyEncoder
We have not one, but FOUR systems of type coercion.
I know that Howard has expressed concern over separation of
concerns as
being the motivator for the additional conversion interfaces, but I
submit
that the additional interfaces, in fact, pollute separation of
concerns.
Take Translator: it's trying to act both as a type coercion system
(value
-> string and back) and as a first-pass validation system.
or:
PrimaryKeyEncoder: acting both as a simplistic batching mechanism (by
stashing the set of keys used into the form, and providing a
mechanism to
convert those keys back to values en masse) and as a type coercion
system
(value -> serializable and back)
I'm not disputing the utility of any of the functions provided by the
various systems. I'm disputing the complexity of the system. For
a novice
user, it's confusing and adds additional learning-burden that
doesn't need
to be there.
Consider, for example, trying to learn a few of the built-in
components:
textfield: translator
Context of links: /normally/ value encoder and decoder (quietly).
Except
when your handler takes a type of Object[]. And then you get back
strings,
and if you don't explicitly arrange for the ValueEncoder to do the
decoding,
tapestry tries to use TypeCoercer, which screws up. (See example
later).
DateField: I would expect translator, but, hey, no, it's not...
it's a
java.text.DateFormat.
Grid: ?? No explicit encoding mechanism provided. Presumably....
value
encoder?
Loop: PrimaryKeyEncoder (<sarcasm>since, clearly, the only thing
we're
/ever/ going to loop over is a database entity with a serializable
primary
key</sarcasm>)
AjaxFormLoop: PrimaryKeyEncoder
Select: PrimaryKeyEnco.... oh... wait... ValueEncoder. Shucks.
Just when I
thought I was starting to get this straight. Oh, right, unlike with
Loop, I
might want to use non-entities in a Select. Clear as mud.
textarea: translator
textfield: translator
Because I've been using tapestry, and T5, for a long while now, I can
understand the rationale behind each of these choices. But from the
perspective of a new user, the framework appears schizophrenic.
In fact, the framework doesn't even always "get it right". Take the
following example:
public class SomeComponent {
@Parameter
private Object[] parameters;
@Component(parameters="context=inherit:context")
private ActionLink someAction;
@Inject
private ComponentResources resources;
void onActionFromSomeAction(Object[] parameters) {
resources.triggerEvent("SomeComponentEvent",parameters,null);
}
}
This seems to be perfectly legitimate code. And is potentially a
very
powerful paradigm. However, try using "SomeComponent" with a
hibernate
entity encoded via the value encoder in the hibernate module, and the
framework explodes. The cause, after some digging, is that the
framework
encodes values into the url using a value encoder, but the decoding
will be
done by type coercer (in the above example). There is a
workaround: provide
your own event context that uses value encoder. But there
shouldn't /need/
for a workaround. Type coercion should just work, with absolutely no
thought from the user. Ironically, this was the case when all we
had was
TypeCoercer. But the additional interfaces obscure that simplicity
and
reliability.
Robert
On Sep 15, 2008, at 9/159:53 AM , Howard Lewis Ship wrote:
On Mon, Sep 15, 2008 at 4:31 AM, Kevin Menard <[EMAIL PROTECTED]>
wrote:
I'll test this is the next few days, but don't expect to see
anything
problematic.
I guess the whole RC thing snuck up on me though. I'd really
like to
see the whole type coercion system looked at again. I know we've
ping-ponged on this a few times, but the framework has evolved a
fair
bit since then and I do think it's worth another look. As Robert
pointed out in TAPESTRY-2491, we have four ways of doing type
coercion:
Translators
Very tied into form mechanics; not general purpose; used for moving
between strings and arbitrary values. User input based, with hooks
for client-side validation.
ValueEncoders
Specific to encoding a value into a string, for use inside a URL or
something similar. Really means for entity values, rather than user
input values.
PrimaryKeyEncoders
Similar to ValueEncoders, but not necessarily a String, just a
Serializable. Also meant for entity values. Includes a performance
optimization that allows many entities to be efficiently pre-loaded.
TypeCoercers
Very low-level; used in tapestry-ioc, not just tapestry-core.
Designed
to be combinable. Primarily meant for converting parameters from
actual types to desired types but often used as the basis of the
other
three.
While I can appreciate the value of each being used in a particular
context, it seems as though the framework is even inconsistent with
its usage at times. Any custom implementation of one almost
implies
an implementation of the others and more often than not a simple
adapter is used because the code is so common between them all. It
strikes me as something that's perhaps over-engineered and the
practicality of a single interface may trump the separation of
concerns benefit. I think it's one of the framework's "gotchas"
that
we could address without much hassle.
I still see the simularities as pretty shallow, and the
differences as
pretty deep.
If we do decide to keep the system as is, I guess that's fine as
well.
It's not really broken. But, I would like to see some discussion
on
it leading to some decisive path.
--
Thanks,
Kevin
On Sat, Sep 13, 2008 at 7:18 PM, Howard Lewis Ship <[EMAIL PROTECTED]
>
wrote:
I've fixed a few more bugs for 5.0.15 and updated the Maven and
src/bin distributions, as previously discussed here.
I've created and uploaded a release of Tapestry 5.0.15, ready to
be
voted upon. This is the release candidate.
The files are uploaded to:
http://people.apache.org/~hlship/tapestry-releases/
and a Maven repository:
http://people.apache.org/~hlship/tapestry-ibiblio-rsynch-repository/
Please examine these files to determine if a new preview release,
5.0.15, is ready.
I've also created a 5.0.15 tag in Subversion:
http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.0.15/
On a successful vote, I'll move the files from these directories
to
the proper distribution directories.
Vote will run for three days; on success I'll move the voted
artifacts
into place and send out appropriate notifications.
I'm looking forward to having several weeks of exposure of the
release
candidate. If no critical, unpatchable errors occur, this can
be the
5.0 GA. I'm already looking forward to doing some ambitious
things in
the 5.1. release.
Howard M. Lewis Ship: +1 (binding)
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
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]
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
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]
