Unfortunately I get a build error (not the aforementioned compile
error, something different) so I'm not able to build tonight.

martijn

On Tue, Jun 24, 2008 at 5:23 PM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
> I can try to do so later this evening (after I've done my duties for
> Wicket in Action)
>
> Martijn
>
> On Tue, Jun 24, 2008 at 5:21 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
>> I personally don't mind changes that cause me migration pain if they
>> actually make it better. I'm looking forward to trying it out.
>> Would it be possible to deploy the snapshots some place so I don't have to
>> go through the build pain?
>>
>> - Brill Pappin
>>
>> On 24-Jun-08, at 1:12 AM, Igor Vaynberg wrote:
>>
>>> development of the 1.4 branch has been quiet lately, this is because
>>> the core team has been busy working on an alternative way of
>>> generifiing the framework. an early result of that effort can be found
>>> here [1]. The key difference in [1] is that we have decoupled the
>>> component from the type of the model.
>>>
>>> here is the list of major differences:
>>>
>>> (1) only components that use their model have a generic type
>>> (components you are likely to call getmodel/getmodelobject on as a
>>> user). so far these are link,form,formcomponent
>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>>> allows for typesafety where it makes sense, and eliminates a ton of
>>> noise from code. we will generify others upon request if a good
>>> usecase is provided and we think it is widely applicable.
>>>
>>> (2) non-generified components do not have IModel<T> get/setModel and T
>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
>>> Object get/setDefaultModelObject. this clearly expresses that the
>>> default component model is not tied to the type of component. this is
>>> a bit of a pain from the code migration point of view, but we think is
>>> worth the effort. generifyed components are free to implement the old
>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>>> see ListItem for an example.
>>>
>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>> is a call for confirmation/discussion from our user base. do try to
>>> port a small project or a part of a larger project you are working on
>>> to the [1] branch to see how the new api feels. if we do like this
>>> more the new branch will be merged into what will be 1.4m3.
>>>
>>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>>
>>> -igor
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to