tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Tapestry property conduit / runtime expression language
Date Wed, 28 Apr 2010 21:38:06 GMT
As I said previously, it's a case of creating new classes vs. using
reflection (in many cases). However, there's still lots of
opportunities to streamline the process I hope.

I can't help feeling that langugages such as Clojure and perhaps Scala
must have similar issues; i.e., an explosion of classes.  I've noticed
that when AOT compiling Clojure code, the final JAR files are several
times the size of the source files (for normal Java code, it's
approximately 1:1).

On Wed, Apr 28, 2010 at 10:23 AM, Christophe Cordenier
<christophe.cordenier@gmail.com> wrote:
> If i can help in anyways to track or fix, i ll be pleased to work on it. The
> resulting api is really worthy
>
> Le 28 avr. 2010 à 18:52, Howard Lewis Ship <hlship@gmail.com> a écrit :
>
>> On Wed, Apr 28, 2010 at 4:54 AM, Christophe Cordenier
>> <christophe.cordenier@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> To avoid some cumbersome hacking or use of ognl, i finally decided to
>>> automatically generate one getter for each know activity type. This was
>>> the
>>> opportunity to test the brand new Component Class Transformation API.
>>>
>>> Thanks to Howard for this great changes, no BodyBuilder anymore.
>>
>> Yes, though the cost seems to be an explosion of classes taking up a
>> big chunk of permgen space.  This has me a bit concerned.
>>
>>>
>>> Best Regards,
>>> Christophe Cordenier.
>>>
>>> 2010/4/28 Christophe Cordenier <christophe.cordenier@gmail.com>
>>>
>>>> Hi
>>>>
>>>> Currently property conduit are created when the page template is parsed,
>>>> i
>>>> guess there is good reasons for that (performance, template validation)
>>>> But what about a property binding that would be able to get informations
>>>> from the returned type and note the type of the accessor.
>>>>
>>>> In my case, i have different blocks that display different type of
>>>> activities. Every activity extends a base one, but each activity has
>>>> specific attributes.
>>>> My first implementation was to define one component per activity and put
>>>> all the generics stuff in base component class.
>>>>
>>>> But i thought it would be more elegant to do it the
>>>> 'PropertyDisplayBlocks'
>>>> way, i mean create a context that contain the datas to display and let a
>>>> service decide which block to display in function of the activity type.
>>>> But
>>>> doing this i am still stuck to my specific attributes problem.
>>>>
>>>> Any idea ?
>>>>
>>>> --
>>>> Regards,
>>>> Christophe Cordenier.
>>>>
>>>> Developer of wooki @wookicentral.com
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Christophe Cordenier.
>>>
>>> Developer of wooki @wookicentral.com
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message