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]

Reply via email to