users, please give us your opinion: what is your take on generics with Wicket

[igor.vaynberg]

i dont think it exposes anything, or that anything is flawed. the
component provides a slot for a default model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.

for example, sometimes i want to have a webmarkupcontainer with a
model and sometimes without.

-igor

On Wed, Jun 4, 2008 at 11:30 AM, Brill Pappin <brill@...> wrote:

> I agree with that and I think that is *the* key point.
> If implementing regular language features exposes a flaw, fix the flaw.
>
> I'm one of those that would rather have to refactor my code to
> "upgrade" to a new major version than try and work around some "flaw"
> just to maintain compatibility.
>
> - Brill Pappin
>
> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
> [...]
>> Personally, I think the whole generics business exposes that the
>> one-one relation between components and models is flawed. Without
>> generics this isn't much of a problem, just the odd unused member and
>> constructor, but as generics aren't as 'optional' it is all very in
>> your face suddenly.
> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Wed, Jun 4, 2008 at 11:35 AM, Brill Pappin <brill@...> wrote:
> Thats a pretty major api change (although it looks simple) maybe that
> should be in the next major release?

It's something we can consider yeah. We'll have to think it through
and get back to the drawing board to see what that means for how
components and models work together though. Consistency is very
important in an API like Wicket's, and consistency is imho a big + in
how models and components currently work together.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daniel Frisk]

I have to admit I haven't read thru all of this thread, so my answer  
might be to something else... But here we go:

I think we actually do something very similar to this in our system,  
we automatically detach any instances of jpa-enitities (replacing them  
with a surrogate with only the class and id) and then get them again  
from the db-cache if the page is reconstructed again. So far it works  
like a charm and the programming model is very convinient. Just dump  
whatever entity you like as member of a component and it is  
automatically detached and then loaded back when needed.

I implemented this by hooking in to serialization, just checking each  
object in ObjectOutputStream.replaceObject and  
ObjectInputStream.resolveObject. Also had to use my own PageMapEntries  
to get a suitable hook. Might work as an idea for your implementation  
perhaps?

// Daniel
jalbum.net


On 2008-06-04, at 19:03, Eelco Hillenius wrote:

> On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg  
> <igor.vaynberg@...> wrote:
>> you still have ondetach()...but for convinience we can automatically
>> detach any imodel fields, i actually wanted to do this for a while...
>
> I tried to write this two days ago, but wasn't able to pull it off...
> I wrote an instantiation listener that introspected on the fields of
> components and replaced IModel members with a proxy. These proxies
> would register themselves with the request cycle for cleaning up
> whenever the getObject was called, and the request cycle then would go
> through the list of registered models and detach them at the end of
> the request. The problem I ran into however is that these members can
> be final, assigned at a later stage (typically are actually) and such.
>
> But if there is some way to automatically detach model members, we
> could get rid of the model member in component and instead just let
> components have models by default where it actually always makes
> sense, such as form components.
>
> Anyway, that's something for 1.5. If it is fixable, I think that would
> be the way out of the generics controversy :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> I implemented this by hooking in to serialization, just checking each object
> in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject.
> Also had to use my own PageMapEntries to get a suitable hook. Might work as
> an idea for your implementation perhaps?

That's a cool idea for individual projects. For Wicket in general
however, the problem would be that it wouldn't work for every session
store (it wouldn't for instance for HttpSessionStore which doesn't
serialize on each request). Also, 1.3's default session store
serializes on each request, but does not reuse that serialized
instance until the back button is used (or if you're doing session
replication and come in through another node I guess). Are you sure
your detachment works like you think it does?

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> Also, 1.3's default session store
> serializes on each request, but does not reuse that serialized
> instance until the back button is used (or if you're doing session
> replication and come in through another node I guess).

It keeps the 'current' page in memory, and reuses that when it can.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
> i dont think it exposes anything, or that anything is flawed. the
> component provides a slot for a default model - it is there totally
> out of convinience. i think what is flawed here is that we tied the
> two types via generics.

It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.

The main issue is that with 1.3 you can simply omit the model, whereas
with generified components the choice to not use a model is explicit
(whether you use void, or an annotation to ignore warnings). Very
annoying if you ask me, and it triggered me to think that this is
another hint that the one-one relationship between components and
models like we have now is somewhat flawed. I'm not saying it totally
stinks and that we should get rid of it tomorrow, just that it is
something we might rethink. You know I'm a fan of rethinking stuff ;-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daniel Frisk]

>> I implemented this by hooking in to serialization, just checking  
>> each object
>> in ObjectOutputStream.replaceObject and  
>> ObjectInputStream.resolveObject.
>> Also had to use my own PageMapEntries to get a suitable hook. Might  
>> work as
>> an idea for your implementation perhaps?
>
> That's a cool idea for individual projects. For Wicket in general
> however, the problem would be that it wouldn't work for every session
> store (it wouldn't for instance for HttpSessionStore which doesn't
> serialize on each request). Also, 1.3's default session store
> serializes on each request, but does not reuse that serialized
> instance until the back button is used (or if you're doing session
> replication and come in through another node I guess). Are you sure
> your detachment works like you think it does?

Well... I haven't actually hooked into the SessionStore but instead  
have implemented a special PageMapEntry that stores a serialized page  
with my "special serialization" (hooked in by overridden  
getPageMapEntry(...) in my BasePage). The special serialization takes  
place when the page is put into the pagemap. If the pagemap entry  
should be stored to disk later it is an object with serialized data  
that gets serialized again. I'm pretty sure it works as I intended and  
it might be generalized. The programming model sure is very nifty.

// Daniel
jalbum.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> Well... I haven't actually hooked into the SessionStore but instead have
> implemented a special PageMapEntry that stores a serialized page with my
> "special serialization" (hooked in by overridden getPageMapEntry(...) in my
> BasePage). The special serialization takes place when the page is put into
> the pagemap. If the pagemap entry should be stored to disk later it is an
> object with serialized data that gets serialized again. I'm pretty sure it
> works as I intended and it might be generalized. The programming model sure
> is very nifty.

Yeah, that sounds right. Nice :-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

not just getModelObject() also the toString variants for rendering and so on
The component has to get its data. Ok this isnt the case for Component
itself or the containers
But for Labels, Links, buttons and all form components it is pretty needed.

So the component should be able to access any way so it can also detach it..

johan



On Wed, Jun 4, 2008 at 9:23 PM, Eelco Hillenius <eelco.hillenius@...>
wrote:

> On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...>
> wrote:
> > i dont think it exposes anything, or that anything is flawed. the
> > component provides a slot for a default model - it is there totally
> > out of convinience. i think what is flawed here is that we tied the
> > two types via generics.
>
> It depends on how you phrase things. It is a fact that currently
> models and components are tightly bound because of 'getModelObject'.
>
> The main issue is that with 1.3 you can simply omit the model, whereas
> with generified components the choice to not use a model is explicit
> (whether you use void, or an annotation to ignore warnings). Very
> annoying if you ask me, and it triggered me to think that this is
> another hint that the one-one relationship between components and
> models like we have now is somewhat flawed. I'm not saying it totally
> stinks and that we should get rid of it tomorrow, just that it is
> something we might rethink. You know I'm a fan of rethinking stuff ;-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Roland Huss]

Brill Pappin wrote:

 I don't know if you have every done true TDD (most people can't or think
they can), but it actually changes your code and the way you write it.
Starting with 2 users of your code makes a significant impact on what it
looks like in the end.

Just out of curiosity: Do you have an example for this or some pointer to someone who has ?

[svenmeier]

A component could add a behavior for each model it wants to use:

public class ModelBehavior extends AbstractBehavior {
  private IModel model;
  public ModelBehavior(IModel model) {
    this.model = model;
  }

  public void detach(Component component) {
    this.model.detach();
  }
}

public class Label extends WebComponent {
  private IModel model;
  public Label(IModel model) {
    add(new ModelBehavior(this.model = model));
  }
}

Detachment will then be automatic.

Sven


Igor Vaynberg schrieb:

> you still have ondetach()...but for convinience we can automatically
> detach any imodel fields, i actually wanted to do this for a while...
>
> -igor
>
> On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner <jcompagner@...> wrote:
>  
>> and if i store it in metadata ;)
>>
>>
>> On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <igor.vaynberg@...>
>> wrote:
>>
>>    
>>> why even have an interface? just detach all imodel fields via reflection!
>>>
>>> -igor
>>>
>>>
>>> On Wed, Jun 4, 2008 at 3:37 AM, James Carman <james@...>
>>> wrote:
>>>      
>>>> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
>>>> <eelco.hillenius@...> wrote:
>>>>        
>>>>>> it all depends, on how and what you're developing.
>>>>>>            
>>>>> Yeah. I actually use less and less models in the regular way nowadays.
>>>>> I use plenty of panels (the app I work on hardly uses separate pages)
>>>>> that nest other panels in them (typically detail views or dialogs)
>>>>> that reuse models of the parent. But indeed YMMV.
>>>>>
>>>>> Personally, I think the whole generics business exposes that the
>>>>> one-one relation between components and models is flawed. Without
>>>>> generics this isn't much of a problem, just the odd unused member and
>>>>> constructor, but as generics aren't as 'optional' it is all very in
>>>>> your face suddenly.
>>>>>
>>>>> I think on the longer term (post 1.4) we should re-think how models
>>>>> work in Wicket. See if we can find an elegant way to make this more
>>>>> flexible (I'm not in favor of the id based thing someone posted
>>>>> earlier btw) without breaking the whole world.
>>>>>
>>>>>          
>>>> We discussed this on ##wicket yesterday.  I asked why we have models
>>>> on all components and someone pointed out that the main reason was
>>>> about the detach stuff I believe.  But, couldn't that be solved by
>>>> having some components that implement something like IModelDriven (or
>>>> IModelBacked or whatever) and the detach logic could apply to only
>>>> those components?  Also, someone has pointed out that when they create
>>>> their own components, they sometimes (such as in Palette) have
>>>> multiple "models" that they deal with.  Allowing components to name
>>>> their models what they want would be nice, too.
>>>>
>>>>        
>>>>> FWIW, I'm still on the fence when it comes to whether we should go for
>>>>> a full or partial (models only) implementation of generics, though I'm
>>>>> leaning towards partial.
>>>>>
>>>>> Eelco
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>          
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>      
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

like i said, i dont mind removing the default slot if we add nice
automatic detachment for fields.

-igor


On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:

> On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> i dont think it exposes anything, or that anything is flawed. the
>> component provides a slot for a default model - it is there totally
>> out of convinience. i think what is flawed here is that we tied the
>> two types via generics.
>
> It depends on how you phrase things. It is a fact that currently
> models and components are tightly bound because of 'getModelObject'.
>
> The main issue is that with 1.3 you can simply omit the model, whereas
> with generified components the choice to not use a model is explicit
> (whether you use void, or an annotation to ignore warnings). Very
> annoying if you ask me, and it triggered me to think that this is
> another hint that the one-one relationship between components and
> models like we have now is somewhat flawed. I'm not saying it totally
> stinks and that we should get rid of it tomorrow, just that it is
> something we might rethink. You know I'm a fan of rethinking stuff ;-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

yuck! :)

-igor

On Wed, Jun 4, 2008 at 2:29 PM, Sven Meier <sven@...> wrote:

> A component could add a behavior for each model it wants to use:
>
> public class ModelBehavior extends AbstractBehavior {
>  private IModel model;
>  public ModelBehavior(IModel model) {
>   this.model = model;
>  }
>
>  public void detach(Component component) {
>   this.model.detach();
>  }
> }
>
> public class Label extends WebComponent {
>  private IModel model;
>  public Label(IModel model) {
>   add(new ModelBehavior(this.model = model));
>  }
> }
>
> Detachment will then be automatic.
>
> Sven
>
>
> Igor Vaynberg schrieb:
>>
>> you still have ondetach()...but for convinience we can automatically
>> detach any imodel fields, i actually wanted to do this for a while...
>>
>> -igor
>>
>> On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner <jcompagner@...>
>> wrote:
>>
>>>
>>> and if i store it in metadata ;)
>>>
>>>
>>> On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <igor.vaynberg@...>
>>> wrote:
>>>
>>>
>>>>
>>>> why even have an interface? just detach all imodel fields via
>>>> reflection!
>>>>
>>>> -igor
>>>>
>>>>
>>>> On Wed, Jun 4, 2008 at 3:37 AM, James Carman
>>>> <james@...>
>>>> wrote:
>>>>
>>>>>
>>>>> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
>>>>> <eelco.hillenius@...> wrote:
>>>>>
>>>>>>>
>>>>>>> it all depends, on how and what you're developing.
>>>>>>>
>>>>>>
>>>>>> Yeah. I actually use less and less models in the regular way nowadays.
>>>>>> I use plenty of panels (the app I work on hardly uses separate pages)
>>>>>> that nest other panels in them (typically detail views or dialogs)
>>>>>> that reuse models of the parent. But indeed YMMV.
>>>>>>
>>>>>> Personally, I think the whole generics business exposes that the
>>>>>> one-one relation between components and models is flawed. Without
>>>>>> generics this isn't much of a problem, just the odd unused member and
>>>>>> constructor, but as generics aren't as 'optional' it is all very in
>>>>>> your face suddenly.
>>>>>>
>>>>>> I think on the longer term (post 1.4) we should re-think how models
>>>>>> work in Wicket. See if we can find an elegant way to make this more
>>>>>> flexible (I'm not in favor of the id based thing someone posted
>>>>>> earlier btw) without breaking the whole world.
>>>>>>
>>>>>>
>>>>>
>>>>> We discussed this on ##wicket yesterday.  I asked why we have models
>>>>> on all components and someone pointed out that the main reason was
>>>>> about the detach stuff I believe.  But, couldn't that be solved by
>>>>> having some components that implement something like IModelDriven (or
>>>>> IModelBacked or whatever) and the detach logic could apply to only
>>>>> those components?  Also, someone has pointed out that when they create
>>>>> their own components, they sometimes (such as in Palette) have
>>>>> multiple "models" that they deal with.  Allowing components to name
>>>>> their models what they want would be nice, too.
>>>>>
>>>>>
>>>>>>
>>>>>> FWIW, I'm still on the fence when it comes to whether we should go for
>>>>>> a full or partial (models only) implementation of generics, though I'm
>>>>>> leaning towards partial.
>>>>>>
>>>>>> Eelco
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dvd-2]

The way 1.3 works currently has been fine with me and any type mismatch
in programming error usually result in crash with obvious location of error  and easily fixed.
So to me, it is optional  and not very important. Switching to java 5 does not mean wicket must include generics, there are many other features in java 5 could be used to enhance wicket. and I feel the most helpful new facilities of wicket could be some powerful widgets, layouts, menus that one can use java api to produce (it could use any JS toolkits). Although it was contended that wicket is server side framework,  without those widgets, it would not help spread its use as a Java web toolkit. It is true one could write javascript for some of them,
but integration with java api would distinguish wicket from the rest.
I know there are some projects like this but it would be nice to have
it in wicket core as a strategic effort.

It might not be worth a huge undertaking for a web framework, considering
there are so many other equally crucial factors such as the
widget issue above to make a web app successful.

>Hi all,
>
>We have had several threads in this and the dev list, and some
>discussions in the public on how to incorporate generics in Wicket.
>
>I'd like to use this thread to gather the opinions of as many regular
>Wicket users as we can. Please help us get an impression of what our
>users think about the issue by completing this simple survey. Note
>that it is not a vote; we only want to get an idea of what you think.
>
>1) Generifying* Wicket
>   [ ] Can best be done like currently in the 1.4 branch, where models
>and components are both generified. I care most about the improved
>static type checking generified models and components give Wicket.
>   [ ] Can best be done in a limited fashion, where we only generify
>IModel but not components. I care more about what generifying can do
>for API clarity (declaring a component to only accept certain models
>for instance) than static type checking.
>   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
>in your opinion here).
>   [ ] .... (anything other than these choices?)
>
>2) How strongly do you feel about your choice above?
>   [ ] Whatever choice ultimately made, I'll happily convert/ start
>using 1.4 and up.
>   [ ] I might rethink upgrading if my choice doesn't win.
>   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
>preference.
>
>Thanks in advance for everyone participating, and pls feel free to
>explain yourself further beyond just answering these questions!
>
>Eelco
>
>p.s. I suggest that the core devs and most active participants and
>previous discussions wait a few days before giving their opinions so
>that we don't flood the thread right from the start.
>
>* Parameterizing would probably be the better word to use, but
>generifying seems to be the word that many people use.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@...
>For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stefan Lindner]

dvd@... wrote
>The way 1.3 works currently has been fine with me and any type mismatch
in programming error usually result in crash with obvious location of
>error  and easily fixed.

This may be an option for small projects or for personal use. But for
big projects for software sold all around the world this is not a good
design. Each error(type mismatch) that can be avoided during development
costs
- less time in quality assurance
- debugging
- maintaining and update releases
And: less money in development at all.

So Generics are not only a nice thing wicket adopts as Java 5 hhas
Generics. It helps us to develop faster and cheaper and to increase the
quality of our software.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

like matej already told you
There is no default "slot" or field..
A component with no model doesnt have a a slot what so ever.

johan


On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg <igor.vaynberg@...>
wrote:

> like i said, i dont mind removing the default slot if we add nice
> automatic detachment for fields.
>
> -igor
>
>
> On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
> > On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...>
> wrote:
> >> i dont think it exposes anything, or that anything is flawed. the
> >> component provides a slot for a default model - it is there totally
> >> out of convinience. i think what is flawed here is that we tied the
> >> two types via generics.
> >
> > It depends on how you phrase things. It is a fact that currently
> > models and components are tightly bound because of 'getModelObject'.
> >
> > The main issue is that with 1.3 you can simply omit the model, whereas
> > with generified components the choice to not use a model is explicit
> > (whether you use void, or an annotation to ignore warnings). Very
> > annoying if you ask me, and it triggered me to think that this is
> > another hint that the one-one relationship between components and
> > models like we have now is somewhat flawed. I'm not saying it totally
> > stinks and that we should get rid of it tomorrow, just that it is
> > something we might rethink. You know I'm a fan of rethinking stuff ;-)
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[igor.vaynberg]

i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:

add(new webmarkupcontainer("foo") {
  private imodel<person> model;
  protected void isvisible() { return model.getobject()!=null; });

then i am perfectly happy. notice how there is no explicit ondetach()
to detach the model. also notice how not having a default model slot
really removes the need for typing the component itself, i can
implement my own typed getmodel() easily. the only thing that breaks
here is wrapping since we no longer have a setmodel...something to
think about

-igor

On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner <jcompagner@...> wrote:

> like matej already told you
> There is no default "slot" or field..
> A component with no model doesnt have a a slot what so ever.
>
> johan
>
>
> On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg <igor.vaynberg@...>
> wrote:
>
>> like i said, i dont mind removing the default slot if we add nice
>> automatic detachment for fields.
>>
>> -igor
>>
>>
>> On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
>> <eelco.hillenius@...> wrote:
>> > On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...>
>> wrote:
>> >> i dont think it exposes anything, or that anything is flawed. the
>> >> component provides a slot for a default model - it is there totally
>> >> out of convinience. i think what is flawed here is that we tied the
>> >> two types via generics.
>> >
>> > It depends on how you phrase things. It is a fact that currently
>> > models and components are tightly bound because of 'getModelObject'.
>> >
>> > The main issue is that with 1.3 you can simply omit the model, whereas
>> > with generified components the choice to not use a model is explicit
>> > (whether you use void, or an annotation to ignore warnings). Very
>> > annoying if you ask me, and it triggered me to think that this is
>> > another hint that the one-one relationship between components and
>> > models like we have now is somewhat flawed. I'm not saying it totally
>> > stinks and that we should get rid of it tomorrow, just that it is
>> > something we might rethink. You know I'm a fan of rethinking stuff ;-)
>> >
>> > Eelco
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[pkcinna]

   [x] Should be avoided, I prefer the way 1.3 works. Because sometimes I still run into web servers like websphere 5.x that still depend on jdk 1.4 (also some tomcat 5.5 hosting sites).  The beauty of Wicket is its simplicity and adding generics doesn't seem be worth the cost.  I like generics but I get tons of warnings in Eclipse now about wicket generics just from using components.  Please focus on making Wicket even more concise, elegant, and easy to use...  seems like thats always where web frameworks fail... they tack on so many features and abstract framework requirements that it becomes a mess.

2) How strongly do you feel about your choice above?
   [x] I might rethink upgrading if my choice doesn't win.
 

[Johan Compagner]

For that we have 1.3

1.4 will be java 5

On 6/5/08, pkcinna <pkcinna@...> wrote:

>
>    [x] Should be avoided, I prefer the way 1.3 works. Because sometimes I
> still run into web servers like websphere 5.x that still depend on jdk 1.4
> (also some tomcat 5.5 hosting sites).  The beauty of Wicket is its
> simplicity and adding generics doesn't seem be worth the cost.  I like
> generics but I get tons of warnings in Eclipse now about wicket generics
> just from using components.  Please focus on making Wicket even more
> concise, elegant, and easy to use...  seems like thats always where web
> frameworks fail... they tack on so many features and abstract framework
> requirements that it becomes a mess.
>
> 2) How strongly do you feel about your choice above?
>    [x] I might rethink upgrading if my choice doesn't win.
>
> --
> View this message in context:
> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17673404.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

This might also screw up stuff like CompoundPropertyModel, no?  We
discussed this a bit on ##wicket.

On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> i didnt mean the memory slot, i ment the actual default model each
> component can have. if i can write something like this:
>
> add(new webmarkupcontainer("foo") {
>  private imodel<person> model;
>  protected void isvisible() { return model.getobject()!=null; });
>
> then i am perfectly happy. notice how there is no explicit ondetach()
> to detach the model. also notice how not having a default model slot
> really removes the need for typing the component itself, i can
> implement my own typed getmodel() easily. the only thing that breaks
> here is wrapping since we no longer have a setmodel...something to
> think about
>
> -igor
>
> On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner <jcompagner@...> wrote:
>> like matej already told you
>> There is no default "slot" or field..
>> A component with no model doesnt have a a slot what so ever.
>>
>> johan
>>
>>
>> On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg <igor.vaynberg@...>
>> wrote:
>>
>>> like i said, i dont mind removing the default slot if we add nice
>>> automatic detachment for fields.
>>>
>>> -igor
>>>
>>>
>>> On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
>>> <eelco.hillenius@...> wrote:
>>> > On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...>
>>> wrote:
>>> >> i dont think it exposes anything, or that anything is flawed. the
>>> >> component provides a slot for a default model - it is there totally
>>> >> out of convinience. i think what is flawed here is that we tied the
>>> >> two types via generics.
>>> >
>>> > It depends on how you phrase things. It is a fact that currently
>>> > models and components are tightly bound because of 'getModelObject'.
>>> >
>>> > The main issue is that with 1.3 you can simply omit the model, whereas
>>> > with generified components the choice to not use a model is explicit
>>> > (whether you use void, or an annotation to ignore warnings). Very
>>> > annoying if you ask me, and it triggered me to think that this is
>>> > another hint that the one-one relationship between components and
>>> > models like we have now is somewhat flawed. I'm not saying it totally
>>> > stinks and that we should get rid of it tomorrow, just that it is
>>> > something we might rethink. You know I'm a fan of rethinking stuff ;-)
>>> >
>>> > Eelco
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@...
>>> > For additional commands, e-mail: users-help@...
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...