subject:"Wicket feedback"

wicket does two things: provides a way to render javascript to
bootstrap a gwt widget in a page and provides callbacks for the gwt
widget to access serverside data.

-igor

On Wed, Dec 23, 2009 at 7:38 AM, Johan Compagner jcompag...@gmail.com wrote:
 On Wed, Dec 23, 2009 at 07:32, Sudhir N sudhir_nima...@yahoo.com wrote:

 One more thing I am still looking for is, integrating GWT. I did that
 before with other framework.




 i asked this question more
 How do you see this integration? What should be integrated. What should
 wicket do? What should GWT do?


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket feedback

and where is this more OO?

-igor

On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
 I vote +1 for more OO Wicket. Way to go Ricardo!

 **
 Martin

 2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com:
 Hi Igor,
 Thanks for your response. Here goes my observations:

 Em 22/12/2009 14:41, Igor Vaynberg escreveu:

 On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
 ricardo.ekm.lis...@gmail.com  wrote:


 Hi all,
 We've just finished with success a wicket project for a large online
 retailer. I think wicket is the best framework out there, but as any
 other
 project there is room for improvement. I will talk about some topics
 bellow,
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to
 add behavior, and we have to add extra markup just to satisfy wicket 1:1
 mapping. Take CheckGroup for exaple, it is a component focused on
 behavior,
 even though we have to add a reference to it in HTML.


 a redesigned CheckGroup is welcome, but that component is the
 exception and not the rule.



 Yes, but how do we deal with the requirement of all components having a HTML
 representation? The same happens with RadioGroup, even with wicket-1055
 solved, the HTML reference is still there.

 When creating composite input fields (like date), the usual way is to
 create
 a panel even if you are not interested in reusability. A interesting
 aproach
 is to insert a hidden text field in HTML mapped to a component that
 controls
 other components input. It makes easier to integrate with designer and to
 preview in browser. If we didn't have this limitation the hidden input
 would
 not be necessary and the development of behavior focused components would
 be
 easier.


 i dont really understand this..the usual way would be to extend a
 FormComponentPanel, not a Panel. are you saying that because the Panel
 derivatives are just adiv  in the markup it makes it difficult for
 the designers?



 You're right, I meant FormComponentPanel. I think it would be better not
 being constrained to have a separate markup just because server side
 processing will be different. After all in HTML terms, a composite input is
 the same as a single input. Another example of unecessary coupling IMO is
 that text area and input text fields are mapped to different components,
 even behaving the same.
 Even if there are internals when manipulating one or another, I think it
 should be handled by wicket because for the programmer it makes no
 difference.

 One thing that bothers me is when our designer move things around in HTML
 and we get added a component in code but forgot to reference it in the
 markup error, because of component hierarchy. Html tags position is a
 view
 problem not a behavior problem, so why bother in java?


 it *is* a behavior problem. markup is what drives the rendering order
 so if you move things around and change the nesting order of
 components then you can have a component that is a child of another
 render *before* the parent which will cause things to go seriously out
 of whack.

 in my company the designers understand that they cannot change the
 nesting of tags with wicket:id attributes, it took an hour to explain
 it to them, and we have not had any problems since. in practice, there
 is no need to do that often anyways...



 IMO learning how to deal with a restriction, isn't better than removing that
 restriction. Even if it doens't happen often, I would be happier if it never
 happens :)
 Render order seems a wicket internal concern to me not a business or
 application behavior concern.



 Another issue, is when we want to change the class of a div, for example,
 and have to change our whole page hierarchy in java, just to manipulate
 that
 tag.


 you dont have to change the hierarchy, just make the component
 attached to that div a transparent resolver by overriding
 isTransparentResolver() and returning true.



 So I think a hierarchy more focused on components behavior (for example
 taking care of inherited models and inputs), rather than tags position in
 HTML would be better. This would make wicket more flexible and easier to
 work with.


 once again, this is only a problem when you change the *nesting* of
 components. if a component can be safely moved outside the parent,
 then why is there a nesting to begin with? why arent the two
 components siblings? the *nesting* is usually there *because* there is
 a functional requirement.

 here is a simple usecase:

 webmarkupcontainer admin=new webmarkupcontainer(admin) { isvisible()
 { return user.isadmin(); }};
 admin.add(new link(delete) {...});

 the code is pretty much self-explanatory, now the designer takes the
 delete link and moves it ouside the wicket:id=admin tag. in your

Re: Wicket feedback

On Wed, Dec 23, 2009 at 7:02 AM, Ricardo Mayerhofer
ricardo.ekm.lis...@gmail.com wrote:
 Hi Igor,
 Thanks for your response. Here goes my observations:

 Em 22/12/2009 14:41, Igor Vaynberg escreveu:

 On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
 ricardo.ekm.lis...@gmail.com  wrote:


 Hi all,
 We've just finished with success a wicket project for a large online
 retailer. I think wicket is the best framework out there, but as any
 other
 project there is room for improvement. I will talk about some topics
 bellow,
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to
 add behavior, and we have to add extra markup just to satisfy wicket 1:1
 mapping. Take CheckGroup for exaple, it is a component focused on
 behavior,
 even though we have to add a reference to it in HTML.


 a redesigned CheckGroup is welcome, but that component is the
 exception and not the rule.



 Yes, but how do we deal with the requirement of all components having a HTML
 representation? The same happens with RadioGroup, even with wicket-1055
 solved, the HTML reference is still there.

CheckGroup and RadioGroup are essentially the same thing as far as the
way they work. once you redesign CheckGroup the RadioGroup update will
be minimal.

i dont think there is a big problem requiring every component to have
an html tag. after all wicket is a component based framework where
components represent ui which is in turn represented by html tags. the
tags also carry with them importance on nesting, so i also dont think
its a problem that wicket components carry the same importance.

come up with a list of usecases where this is inconvenient and if
there are a lot we can address them. but i cant really see many past
Check/RadioGroup components.

 When creating composite input fields (like date), the usual way is to
 create
 a panel even if you are not interested in reusability. A interesting
 aproach
 is to insert a hidden text field in HTML mapped to a component that
 controls
 other components input. It makes easier to integrate with designer and to
 preview in browser. If we didn't have this limitation the hidden input
 would
 not be necessary and the development of behavior focused components would
 be
 easier.


 i dont really understand this..the usual way would be to extend a
 FormComponentPanel, not a Panel. are you saying that because the Panel
 derivatives are just adiv  in the markup it makes it difficult for
 the designers?



 You're right, I meant FormComponentPanel. I think it would be better not
 being constrained to have a separate markup just because server side
 processing will be different. After all in HTML terms, a composite input is
 the same as a single input.

this has nothing to do with the difference in server-side processing,
this is more a design choice that promotes good reuse. lets say you
create a compound component that has two select boxes. if you do not
make it into a panel that means everywhere you use it you *have* to
know what kind of markup to put in, what the wicket:id values are for
the two select boxes that it uses, etc. in the future if you modify
this component to have a container around the two select boxes you now
have to find every place in your project where you used this component
and add the container. sounds like pita to me.

 Another example of unecessary coupling IMO is
 that text area and input text fields are mapped to different components,
 even behaving the same.
 Even if there are internals when manipulating one or another, I think it
 should be handled by wicket because for the programmer it makes no
 difference.

agreed. we already do this with links and buttons. my guess is that it
has never bothered anyone enough to create an rfe.

 One thing that bothers me is when our designer move things around in HTML
 and we get added a component in code but forgot to reference it in the
 markup error, because of component hierarchy. Html tags position is a
 view
 problem not a behavior problem, so why bother in java?


 it *is* a behavior problem. markup is what drives the rendering order
 so if you move things around and change the nesting order of
 components then you can have a component that is a child of another
 render *before* the parent which will cause things to go seriously out
 of whack.

 in my company the designers understand that they cannot change the
 nesting of tags with wicket:id attributes, it took an hour to explain
 it to them, and we have not had any problems since. in practice, there
 is no need to do that often anyways...



 IMO learning how to deal with a restriction, isn't better than removing that
 restriction. Even if it doens't happen often, I would be happier if it never
 happens :)
 Render order seems a wicket internal concern to

Re: Wicket feedback

2009-12-23 Thread nmelen...@getsense.com.ar

It is HTTP!  and we can use OOP very well.
Wicket makes it possible.
+1 for wicket :)
NM


On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 and where is this more OO?

 -igor

 On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
  I vote +1 for more OO Wicket. Way to go Ricardo!
 
  **
  Martin
 
  2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com:
  Hi Igor,
  Thanks for your response. Here goes my observations:
 
  Em 22/12/2009 14:41, Igor Vaynberg escreveu:
 
  On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
  ricardo.ekm.lis...@gmail.com  wrote:
 
 
  Hi all,
  We've just finished with success a wicket project for a large online
  retailer. I think wicket is the best framework out there, but as any
  other
  project there is room for improvement. I will talk about some topics
  bellow,
  I hope it can help in some way.
 
  - Separation of corcerns
  I think we could get a better separation of concerns if page class
 were
  focused more in behavior and html were more focused in display (or
 view).
  What I mean is, some times we have components that the main purpose is
 to
  add behavior, and we have to add extra markup just to satisfy wicket
 1:1
  mapping. Take CheckGroup for exaple, it is a component focused on
  behavior,
  even though we have to add a reference to it in HTML.
 
 
  a redesigned CheckGroup is welcome, but that component is the
  exception and not the rule.
 
 
 
  Yes, but how do we deal with the requirement of all components having a
 HTML
  representation? The same happens with RadioGroup, even with wicket-1055
  solved, the HTML reference is still there.
 
  When creating composite input fields (like date), the usual way is to
  create
  a panel even if you are not interested in reusability. A interesting
  aproach
  is to insert a hidden text field in HTML mapped to a component that
  controls
  other components input. It makes easier to integrate with designer and
 to
  preview in browser. If we didn't have this limitation the hidden input
  would
  not be necessary and the development of behavior focused components
 would
  be
  easier.
 
 
  i dont really understand this..the usual way would be to extend a
  FormComponentPanel, not a Panel. are you saying that because the Panel
  derivatives are just adiv  in the markup it makes it difficult for
  the designers?
 
 
 
  You're right, I meant FormComponentPanel. I think it would be better not
  being constrained to have a separate markup just because server side
  processing will be different. After all in HTML terms, a composite input
 is
  the same as a single input. Another example of unecessary coupling IMO
 is
  that text area and input text fields are mapped to different components,
  even behaving the same.
  Even if there are internals when manipulating one or another, I think it
  should be handled by wicket because for the programmer it makes no
  difference.
 
  One thing that bothers me is when our designer move things around in
 HTML
  and we get added a component in code but forgot to reference it in
 the
  markup error, because of component hierarchy. Html tags position is a
  view
  problem not a behavior problem, so why bother in java?
 
 
  it *is* a behavior problem. markup is what drives the rendering order
  so if you move things around and change the nesting order of
  components then you can have a component that is a child of another
  render *before* the parent which will cause things to go seriously out
  of whack.
 
  in my company the designers understand that they cannot change the
  nesting of tags with wicket:id attributes, it took an hour to explain
  it to them, and we have not had any problems since. in practice, there
  is no need to do that often anyways...
 
 
 
  IMO learning how to deal with a restriction, isn't better than removing
 that
  restriction. Even if it doens't happen often, I would be happier if it
 never
  happens :)
  Render order seems a wicket internal concern to me not a business or
  application behavior concern.
 
 
 
  Another issue, is when we want to change the class of a div, for
 example,
  and have to change our whole page hierarchy in java, just to
 manipulate
  that
  tag.
 
 
  you dont have to change the hierarchy, just make the component
  attached to that div a transparent resolver by overriding
  isTransparentResolver() and returning true.
 
 
 
  So I think a hierarchy more focused on components behavior (for
 example
  taking care of inherited models and inputs), rather than tags position
 in
  HTML would be better. This would make wicket more flexible and easier
 to
  work with.
 
 
  once again, this is only a problem when you change the *nesting* of
  components. if a component can be safely moved outside the parent,
  then why is there a nesting to begin with? why arent the two
  components siblings? the *nesting* is usually there *because* there is
  a functional

Re: Wicket feedback

2009-12-23 Thread Martin Makundi

More OO is less synchronization between markup and wicket.

It should be sufficient that the artist thinks the gfx are immacculate
and that the java developer thinks the code is immacculate. Why do we
need to couple java with html hierarchies and stuff? Some namespace
attribute could suffice to allow nested components.

**
Martin

 On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 and where is this more OO?

 -igor

 On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
  I vote +1 for more OO Wicket. Way to go Ricardo!
 
  **
  Martin
 
  2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com:
  Hi Igor,
  Thanks for your response. Here goes my observations:
 
  Em 22/12/2009 14:41, Igor Vaynberg escreveu:
 
  On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
  ricardo.ekm.lis...@gmail.com  wrote:
 
 
  Hi all,
  We've just finished with success a wicket project for a large online
  retailer. I think wicket is the best framework out there, but as any
  other
  project there is room for improvement. I will talk about some topics
  bellow,
  I hope it can help in some way.
 
  - Separation of corcerns
  I think we could get a better separation of concerns if page class
 were
  focused more in behavior and html were more focused in display (or
 view).
  What I mean is, some times we have components that the main purpose is
 to
  add behavior, and we have to add extra markup just to satisfy wicket
 1:1
  mapping. Take CheckGroup for exaple, it is a component focused on
  behavior,
  even though we have to add a reference to it in HTML.
 
 
  a redesigned CheckGroup is welcome, but that component is the
  exception and not the rule.
 
 
 
  Yes, but how do we deal with the requirement of all components having a
 HTML
  representation? The same happens with RadioGroup, even with wicket-1055
  solved, the HTML reference is still there.
 
  When creating composite input fields (like date), the usual way is to
  create
  a panel even if you are not interested in reusability. A interesting
  aproach
  is to insert a hidden text field in HTML mapped to a component that
  controls
  other components input. It makes easier to integrate with designer and
 to
  preview in browser. If we didn't have this limitation the hidden input
  would
  not be necessary and the development of behavior focused components
 would
  be
  easier.
 
 
  i dont really understand this..the usual way would be to extend a
  FormComponentPanel, not a Panel. are you saying that because the Panel
  derivatives are just adiv  in the markup it makes it difficult for
  the designers?
 
 
 
  You're right, I meant FormComponentPanel. I think it would be better not
  being constrained to have a separate markup just because server side
  processing will be different. After all in HTML terms, a composite input
 is
  the same as a single input. Another example of unecessary coupling IMO
 is
  that text area and input text fields are mapped to different components,
  even behaving the same.
  Even if there are internals when manipulating one or another, I think it
  should be handled by wicket because for the programmer it makes no
  difference.
 
  One thing that bothers me is when our designer move things around in
 HTML
  and we get added a component in code but forgot to reference it in
 the
  markup error, because of component hierarchy. Html tags position is a
  view
  problem not a behavior problem, so why bother in java?
 
 
  it *is* a behavior problem. markup is what drives the rendering order
  so if you move things around and change the nesting order of
  components then you can have a component that is a child of another
  render *before* the parent which will cause things to go seriously out
  of whack.
 
  in my company the designers understand that they cannot change the
  nesting of tags with wicket:id attributes, it took an hour to explain
  it to them, and we have not had any problems since. in practice, there
  is no need to do that often anyways...
 
 
 
  IMO learning how to deal with a restriction, isn't better than removing
 that
  restriction. Even if it doens't happen often, I would be happier if it
 never
  happens :)
  Render order seems a wicket internal concern to me not a business or
  application behavior concern.
 
 
 
  Another issue, is when we want to change the class of a div, for
 example,
  and have to change our whole page hierarchy in java, just to
 manipulate
  that
  tag.
 
 
  you dont have to change the hierarchy, just make the component
  attached to that div a transparent resolver by overriding
  isTransparentResolver() and returning true.
 
 
 
  So I think a hierarchy more focused on components behavior (for
 example
  taking care of inherited models and inputs), rather than tags position
 in
  HTML would be better. This would make wicket more flexible and easier
 to
  work with.
 
 
  once again, this is only a problem when you

Re: Wicket feedback

On Wed, Dec 23, 2009 at 10:53 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
 More OO is less synchronization between markup and wicket.

what does that have to do with OO exactly?

 It should be sufficient that the artist thinks the gfx are immacculate
 and that the java developer thinks the code is immacculate. Why do we
 need to couple java with html hierarchies and stuff? Some namespace
 attribute could suffice to allow nested components.

put your money where your mouth is, come up with a prototype.

-igor


 **
 Martin

 On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 and where is this more OO?

 -igor

 On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
  I vote +1 for more OO Wicket. Way to go Ricardo!
 
  **
  Martin
 
  2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com:
  Hi Igor,
  Thanks for your response. Here goes my observations:
 
  Em 22/12/2009 14:41, Igor Vaynberg escreveu:
 
  On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
  ricardo.ekm.lis...@gmail.com  wrote:
 
 
  Hi all,
  We've just finished with success a wicket project for a large online
  retailer. I think wicket is the best framework out there, but as any
  other
  project there is room for improvement. I will talk about some topics
  bellow,
  I hope it can help in some way.
 
  - Separation of corcerns
  I think we could get a better separation of concerns if page class
 were
  focused more in behavior and html were more focused in display (or
 view).
  What I mean is, some times we have components that the main purpose is
 to
  add behavior, and we have to add extra markup just to satisfy wicket
 1:1
  mapping. Take CheckGroup for exaple, it is a component focused on
  behavior,
  even though we have to add a reference to it in HTML.
 
 
  a redesigned CheckGroup is welcome, but that component is the
  exception and not the rule.
 
 
 
  Yes, but how do we deal with the requirement of all components having a
 HTML
  representation? The same happens with RadioGroup, even with wicket-1055
  solved, the HTML reference is still there.
 
  When creating composite input fields (like date), the usual way is to
  create
  a panel even if you are not interested in reusability. A interesting
  aproach
  is to insert a hidden text field in HTML mapped to a component that
  controls
  other components input. It makes easier to integrate with designer and
 to
  preview in browser. If we didn't have this limitation the hidden input
  would
  not be necessary and the development of behavior focused components
 would
  be
  easier.
 
 
  i dont really understand this..the usual way would be to extend a
  FormComponentPanel, not a Panel. are you saying that because the Panel
  derivatives are just adiv  in the markup it makes it difficult for
  the designers?
 
 
 
  You're right, I meant FormComponentPanel. I think it would be better not
  being constrained to have a separate markup just because server side
  processing will be different. After all in HTML terms, a composite input
 is
  the same as a single input. Another example of unecessary coupling IMO
 is
  that text area and input text fields are mapped to different components,
  even behaving the same.
  Even if there are internals when manipulating one or another, I think it
  should be handled by wicket because for the programmer it makes no
  difference.
 
  One thing that bothers me is when our designer move things around in
 HTML
  and we get added a component in code but forgot to reference it in
 the
  markup error, because of component hierarchy. Html tags position is a
  view
  problem not a behavior problem, so why bother in java?
 
 
  it *is* a behavior problem. markup is what drives the rendering order
  so if you move things around and change the nesting order of
  components then you can have a component that is a child of another
  render *before* the parent which will cause things to go seriously out
  of whack.
 
  in my company the designers understand that they cannot change the
  nesting of tags with wicket:id attributes, it took an hour to explain
  it to them, and we have not had any problems since. in practice, there
  is no need to do that often anyways...
 
 
 
  IMO learning how to deal with a restriction, isn't better than removing
 that
  restriction. Even if it doens't happen often, I would be happier if it
 never
  happens :)
  Render order seems a wicket internal concern to me not a business or
  application behavior concern.
 
 
 
  Another issue, is when we want to change the class of a div, for
 example,
  and have to change our whole page hierarchy in java, just to
 manipulate
  that
  tag.
 
 
  you dont have to change the hierarchy, just make the component
  attached to that div a transparent resolver by overriding
  isTransparentResolver() and returning true.
 
 
 
  So I think a hierarchy more focused on components behavior (for
 example

Re: Wicket feedback

2009-12-23 Thread nmelen...@getsense.com.ar

i think it is a trade off.
we synchronize with the markup and lose some OOP, but we gain in desing.
Have you ever change the look and feel of your application? with wicket it
is really easy, in other frameworks it is a nightmare.
NM


On Wed, Dec 23, 2009 at 3:53 PM, Martin Makundi 
martin.maku...@koodaripalvelut.com wrote:

 More OO is less synchronization between markup and wicket.

 It should be sufficient that the artist thinks the gfx are immacculate
 and that the java developer thinks the code is immacculate. Why do we
 need to couple java with html hierarchies and stuff? Some namespace
 attribute could suffice to allow nested components.

 **
 Martin

  On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 
  and where is this more OO?
 
  -igor
 
  On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
  martin.maku...@koodaripalvelut.com wrote:
   I vote +1 for more OO Wicket. Way to go Ricardo!
  
   **
   Martin
  
   2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com:
   Hi Igor,
   Thanks for your response. Here goes my observations:
  
   Em 22/12/2009 14:41, Igor Vaynberg escreveu:
  
   On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
   ricardo.ekm.lis...@gmail.com  wrote:
  
  
   Hi all,
   We've just finished with success a wicket project for a large
 online
   retailer. I think wicket is the best framework out there, but as
 any
   other
   project there is room for improvement. I will talk about some
 topics
   bellow,
   I hope it can help in some way.
  
   - Separation of corcerns
   I think we could get a better separation of concerns if page class
  were
   focused more in behavior and html were more focused in display (or
  view).
   What I mean is, some times we have components that the main purpose
 is
  to
   add behavior, and we have to add extra markup just to satisfy
 wicket
  1:1
   mapping. Take CheckGroup for exaple, it is a component focused on
   behavior,
   even though we have to add a reference to it in HTML.
  
  
   a redesigned CheckGroup is welcome, but that component is the
   exception and not the rule.
  
  
  
   Yes, but how do we deal with the requirement of all components having
 a
  HTML
   representation? The same happens with RadioGroup, even with
 wicket-1055
   solved, the HTML reference is still there.
  
   When creating composite input fields (like date), the usual way is
 to
   create
   a panel even if you are not interested in reusability. A
 interesting
   aproach
   is to insert a hidden text field in HTML mapped to a component that
   controls
   other components input. It makes easier to integrate with designer
 and
  to
   preview in browser. If we didn't have this limitation the hidden
 input
   would
   not be necessary and the development of behavior focused components
  would
   be
   easier.
  
  
   i dont really understand this..the usual way would be to extend a
   FormComponentPanel, not a Panel. are you saying that because the
 Panel
   derivatives are just adiv  in the markup it makes it difficult for
   the designers?
  
  
  
   You're right, I meant FormComponentPanel. I think it would be better
 not
   being constrained to have a separate markup just because server side
   processing will be different. After all in HTML terms, a composite
 input
  is
   the same as a single input. Another example of unecessary coupling
 IMO
  is
   that text area and input text fields are mapped to different
 components,
   even behaving the same.
   Even if there are internals when manipulating one or another, I think
 it
   should be handled by wicket because for the programmer it makes no
   difference.
  
   One thing that bothers me is when our designer move things around
 in
  HTML
   and we get added a component in code but forgot to reference it in
  the
   markup error, because of component hierarchy. Html tags position
 is a
   view
   problem not a behavior problem, so why bother in java?
  
  
   it *is* a behavior problem. markup is what drives the rendering
 order
   so if you move things around and change the nesting order of
   components then you can have a component that is a child of another
   render *before* the parent which will cause things to go seriously
 out
   of whack.
  
   in my company the designers understand that they cannot change the
   nesting of tags with wicket:id attributes, it took an hour to
 explain
   it to them, and we have not had any problems since. in practice,
 there
   is no need to do that often anyways...
  
  
  
   IMO learning how to deal with a restriction, isn't better than
 removing
  that
   restriction. Even if it doens't happen often, I would be happier if
 it
  never
   happens :)
   Render order seems a wicket internal concern to me not a business or
   application behavior concern.
  
  
  
   Another issue, is when we want to change the class of a div, for
  example,
   and have to change our whole page hierarchy in java, just to
  manipulate

Re: Wicket feedback

2009-12-23 Thread Martin Makundi

 what does that have to do with OO exactly?

hmm..

 It should be sufficient that the artist thinks the gfx are immacculate
 and that the java developer thinks the code is immacculate. Why do we
 need to couple java with html hierarchies and stuff? Some namespace
 attribute could suffice to allow nested components.

 put your money where your mouth is, come up with a prototype.

Does wicket have a single point where it manages which component
becomes the child of another and where the markup is loaded from? If
yes, I could try to introduce a namespace attribute.

 we synchronize with the markup and lose some OOP, but we gain in desing.
 Have you ever change the look and feel of your application? with wicket it
 is really easy, in other frameworks it is a nightmare.

If you give up coupling between html and java you do not lose the ease
of design. Actually you will gain more ease and freedom of design.

Furthermore, coding will be much faster as in most (80-90%) cases you
need only a single namespace per panel and you could go about it
without the need to worry about how the components are nested in html
 java.

When I build a new panel I believe a significant amount of time is
spent in synchronizing html and java. That's work time spent that is
not really adding value in linear amount.

**
Martin


 -igor


 **
 Martin

 On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 and where is this more OO?

 -igor

 On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
  I vote +1 for more OO Wicket. Way to go Ricardo!
 
  **
  Martin
 
  2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com:
  Hi Igor,
  Thanks for your response. Here goes my observations:
 
  Em 22/12/2009 14:41, Igor Vaynberg escreveu:
 
  On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
  ricardo.ekm.lis...@gmail.com  wrote:
 
 
  Hi all,
  We've just finished with success a wicket project for a large online
  retailer. I think wicket is the best framework out there, but as any
  other
  project there is room for improvement. I will talk about some topics
  bellow,
  I hope it can help in some way.
 
  - Separation of corcerns
  I think we could get a better separation of concerns if page class
 were
  focused more in behavior and html were more focused in display (or
 view).
  What I mean is, some times we have components that the main purpose is
 to
  add behavior, and we have to add extra markup just to satisfy wicket
 1:1
  mapping. Take CheckGroup for exaple, it is a component focused on
  behavior,
  even though we have to add a reference to it in HTML.
 
 
  a redesigned CheckGroup is welcome, but that component is the
  exception and not the rule.
 
 
 
  Yes, but how do we deal with the requirement of all components having a
 HTML
  representation? The same happens with RadioGroup, even with wicket-1055
  solved, the HTML reference is still there.
 
  When creating composite input fields (like date), the usual way is to
  create
  a panel even if you are not interested in reusability. A interesting
  aproach
  is to insert a hidden text field in HTML mapped to a component that
  controls
  other components input. It makes easier to integrate with designer and
 to
  preview in browser. If we didn't have this limitation the hidden input
  would
  not be necessary and the development of behavior focused components
 would
  be
  easier.
 
 
  i dont really understand this..the usual way would be to extend a
  FormComponentPanel, not a Panel. are you saying that because the Panel
  derivatives are just adiv  in the markup it makes it difficult for
  the designers?
 
 
 
  You're right, I meant FormComponentPanel. I think it would be better not
  being constrained to have a separate markup just because server side
  processing will be different. After all in HTML terms, a composite input
 is
  the same as a single input. Another example of unecessary coupling IMO
 is
  that text area and input text fields are mapped to different components,
  even behaving the same.
  Even if there are internals when manipulating one or another, I think it
  should be handled by wicket because for the programmer it makes no
  difference.
 
  One thing that bothers me is when our designer move things around in
 HTML
  and we get added a component in code but forgot to reference it in
 the
  markup error, because of component hierarchy. Html tags position is a
  view
  problem not a behavior problem, so why bother in java?
 
 
  it *is* a behavior problem. markup is what drives the rendering order
  so if you move things around and change the nesting order of
  components then you can have a component that is a child of another
  render *before* the parent which will cause things to go seriously out
  of whack.
 
  in my company the designers understand that they cannot change the
  nesting of tags with wicket:id attributes, it took an hour to explain
  it to them, and we have not had

Re: Wicket feedback

you have the sources, you can build whatever infrastructure you need
that is missing. lets see it.

-igor

On Wed, Dec 23, 2009 at 11:15 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
 what does that have to do with OO exactly?

 hmm..

 It should be sufficient that the artist thinks the gfx are immacculate
 and that the java developer thinks the code is immacculate. Why do we
 need to couple java with html hierarchies and stuff? Some namespace
 attribute could suffice to allow nested components.

 put your money where your mouth is, come up with a prototype.

 Does wicket have a single point where it manages which component
 becomes the child of another and where the markup is loaded from? If
 yes, I could try to introduce a namespace attribute.

 we synchronize with the markup and lose some OOP, but we gain in desing.
 Have you ever change the look and feel of your application? with wicket it
 is really easy, in other frameworks it is a nightmare.

 If you give up coupling between html and java you do not lose the ease
 of design. Actually you will gain more ease and freedom of design.

 Furthermore, coding will be much faster as in most (80-90%) cases you
 need only a single namespace per panel and you could go about it
 without the need to worry about how the components are nested in html
  java.

 When I build a new panel I believe a significant amount of time is
 spent in synchronizing html and java. That's work time spent that is
 not really adding value in linear amount.

 **
 Martin


 -igor


 **
 Martin

 On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 and where is this more OO?

 -igor

 On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
  I vote +1 for more OO Wicket. Way to go Ricardo!
 
  **
  Martin
 
  2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com:
  Hi Igor,
  Thanks for your response. Here goes my observations:
 
  Em 22/12/2009 14:41, Igor Vaynberg escreveu:
 
  On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
  ricardo.ekm.lis...@gmail.com  wrote:
 
 
  Hi all,
  We've just finished with success a wicket project for a large online
  retailer. I think wicket is the best framework out there, but as any
  other
  project there is room for improvement. I will talk about some topics
  bellow,
  I hope it can help in some way.
 
  - Separation of corcerns
  I think we could get a better separation of concerns if page class
 were
  focused more in behavior and html were more focused in display (or
 view).
  What I mean is, some times we have components that the main purpose 
  is
 to
  add behavior, and we have to add extra markup just to satisfy wicket
 1:1
  mapping. Take CheckGroup for exaple, it is a component focused on
  behavior,
  even though we have to add a reference to it in HTML.
 
 
  a redesigned CheckGroup is welcome, but that component is the
  exception and not the rule.
 
 
 
  Yes, but how do we deal with the requirement of all components having a
 HTML
  representation? The same happens with RadioGroup, even with wicket-1055
  solved, the HTML reference is still there.
 
  When creating composite input fields (like date), the usual way is to
  create
  a panel even if you are not interested in reusability. A interesting
  aproach
  is to insert a hidden text field in HTML mapped to a component that
  controls
  other components input. It makes easier to integrate with designer 
  and
 to
  preview in browser. If we didn't have this limitation the hidden 
  input
  would
  not be necessary and the development of behavior focused components
 would
  be
  easier.
 
 
  i dont really understand this..the usual way would be to extend a
  FormComponentPanel, not a Panel. are you saying that because the Panel
  derivatives are just adiv  in the markup it makes it difficult for
  the designers?
 
 
 
  You're right, I meant FormComponentPanel. I think it would be better 
  not
  being constrained to have a separate markup just because server side
  processing will be different. After all in HTML terms, a composite 
  input
 is
  the same as a single input. Another example of unecessary coupling IMO
 is
  that text area and input text fields are mapped to different 
  components,
  even behaving the same.
  Even if there are internals when manipulating one or another, I think 
  it
  should be handled by wicket because for the programmer it makes no
  difference.
 
  One thing that bothers me is when our designer move things around in
 HTML
  and we get added a component in code but forgot to reference it in
 the
  markup error, because of component hierarchy. Html tags position is 
  a
  view
  problem not a behavior problem, so why bother in java?
 
 
  it *is* a behavior problem. markup is what drives the rendering order
  so if you move things around and change the nesting order of
  components then you can have a component that is a child of another
  render *before* the

Re: Wicket feedback

2009-12-23 Thread Ricardo Mayerhofer


Good discussion.

Em 23/12/2009 15:32, Igor Vaynberg escreveu:

On Wed, Dec 23, 2009 at 7:02 AM, Ricardo Mayerhofer
ricardo.ekm.lis...@gmail.com  wrote:
   

Hi Igor,
Thanks for your response. Here goes my observations:

Em 22/12/2009 14:41, Igor Vaynberg escreveu:
 

On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
ricardo.ekm.lis...@gmail.comwrote:

   

Hi all,
We've just finished with success a wicket project for a large online
retailer. I think wicket is the best framework out there, but as any
other
project there is room for improvement. I will talk about some topics
bellow,
I hope it can help in some way.

- Separation of corcerns
I think we could get a better separation of concerns if page class were
focused more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is to
add behavior, and we have to add extra markup just to satisfy wicket 1:1
mapping. Take CheckGroup for exaple, it is a component focused on
behavior,
even though we have to add a reference to it in HTML.

 

a redesigned CheckGroup is welcome, but that component is the
exception and not the rule.


   

Yes, but how do we deal with the requirement of all components having a HTML
representation? The same happens with RadioGroup, even with wicket-1055
solved, the HTML reference is still there.
 

CheckGroup and RadioGroup are essentially the same thing as far as the
way they work. once you redesign CheckGroup the RadioGroup update will
be minimal.f

i dont think there is a big problem requiring every component to have
an html tag. after all wicket is a component based framework where
components represent ui which is in turn represented by html tags. the
tags also carry with them importance on nesting, so i also dont think
its a problem that wicket components carry the same importance.
   
I think that components should not represent UI, because if you do so 
you will get a very strong coupling between both. I think it should be 
there to add behavior to UI.
It's mainly a philosofical difference that has many implications. For 
example, if we go with the last there won't be TextArea, TextField, 
HiddenField and PasswordField. Only a text field component, that 
represents behavior for this kind of input. The same for buttons and links.
You also solve checkgroup and radiogroup useless tag problem, and open 
doors for components that the main purpose is to add behavior to the 
page, even if not directly related to one specific tag.
That's the very example you gave, a webmarkupcontainer that controls 
other components visibility. There is no need to map the container to HTML.


Also if we loose this coupling we can change java and html in a more 
independent way, resulting in more flexibility.



come up with a list of usecases where this is inconvenient and if
there are a lot we can address them. but i cant really see many past
Check/RadioGroup components.
   

When creating composite input fields (like date), the usual way is to
create
a panel even if you are not interested in reusability. A interesting
aproach
is to insert a hidden text field in HTML mapped to a component that
controls
other components input. It makes easier to integrate with designer and to
preview in browser. If we didn't have this limitation the hidden input
would
not be necessary and the development of behavior focused components would
be
easier.

 

i dont really understand this..the usual way would be to extend a
FormComponentPanel, not a Panel. are you saying that because the Panel
derivatives are just adivin the markup it makes it difficult for
the designers?


   

You're right, I meant FormComponentPanel. I think it would be better not
being constrained to have a separate markup just because server side
processing will be different. After all in HTML terms, a composite input is
the same as a single input.
 

this has nothing to do with the difference in server-side processing,
this is more a design choice that promotes good reuse. lets say you
create a compound component that has two select boxes. if you do not
make it into a panel that means everywhere you use it you *have* to
know what kind of markup to put in, what the wicket:id values are for
the two select boxes that it uses, etc. in the future if you modify
this component to have a container around the two select boxes you now
have to find every place in your project where you used this component
and add the container. sounds like pita to me.

   
We usually start simpler and if required by another piece of 
functionaly, we start generalizing and extracting components. Even if 
you know from the start you need a reusable components, it's nice to 
take baby steps, do the simpler, make it work, and then extract it.
It's great to have the option of getting a reusable composite component, 
but the problem is that there is no way of doing different.



Another example of unecessary

Re: Wicket feedback

On Wed, Dec 23, 2009 at 12:51 PM, Ricardo Mayerhofer
ricardo.ekm.lis...@gmail.com wrote:
 Good discussion.

 Em 23/12/2009 15:32, Igor Vaynberg escreveu:

 On Wed, Dec 23, 2009 at 7:02 AM, Ricardo Mayerhofer
 ricardo.ekm.lis...@gmail.com  wrote:


 Hi Igor,
 Thanks for your response. Here goes my observations:

 Em 22/12/2009 14:41, Igor Vaynberg escreveu:


 On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
 ricardo.ekm.lis...@gmail.com    wrote:



 Hi all,
 We've just finished with success a wicket project for a large online
 retailer. I think wicket is the best framework out there, but as any
 other
 project there is room for improvement. I will talk about some topics
 bellow,
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were
 focused more in behavior and html were more focused in display (or
 view).
 What I mean is, some times we have components that the main purpose is
 to
 add behavior, and we have to add extra markup just to satisfy wicket
 1:1
 mapping. Take CheckGroup for exaple, it is a component focused on
 behavior,
 even though we have to add a reference to it in HTML.



 a redesigned CheckGroup is welcome, but that component is the
 exception and not the rule.




 Yes, but how do we deal with the requirement of all components having a
 HTML
 representation? The same happens with RadioGroup, even with wicket-1055
 solved, the HTML reference is still there.


 CheckGroup and RadioGroup are essentially the same thing as far as the
 way they work. once you redesign CheckGroup the RadioGroup update will
 be minimal.f

 i dont think there is a big problem requiring every component to have
 an html tag. after all wicket is a component based framework where
 components represent ui which is in turn represented by html tags. the
 tags also carry with them importance on nesting, so i also dont think
 its a problem that wicket components carry the same importance.


 I think that components should not represent UI, because if you do so you
 will get a very strong coupling between both. I think it should be there to
 add behavior to UI.

heh, the whole point of wicket is to build UI so there has to be coupling.

 It's mainly a philosofical difference that has many implications. For
 example, if we go with the last there won't be TextArea, TextField,
 HiddenField and PasswordField. Only a text field component, that represents
 behavior for this kind of input.

ok. lets say there is no textarea component only a textfield. how do
we add support for attributes that textarea supports that input tags
dont, such as cols and rows. lets say i have a requirement to control
those pragmatically.

if we have no textarea component then i have to use attribute
modifiers or some other means to add the cols and rows attributes, but
by doing so any knowledge of how they work and what constraints they
have is completely decoupled from the component - which is not a good
thing because you have traded coupling for encapsulation. the very
basic principal of OOP is that your data is coupled to the behavior
that modifies the data - an Object.

 The same for buttons and links.

these are all simple components. what happens when we talk about
components that compose others? such as the DataTable that composes
Items that compose user's other Components that represent rows?

 You also solve checkgroup and radiogroup useless tag problem, and open doors
 for components that the main purpose is to add behavior to the page, even if
 not directly related to one specific tag.

lets see a concrete way of how this will work. do we now have
something in Component hierarchy that is an non-rendered component?
how do all the current cascades and visitors work with this?

 That's the very example you gave, a webmarkupcontainer that controls other
 components visibility. There is no need to map the container to HTML.

in some cases maybe not, but in most cases that will be non-functional
markup that is under this container that you also want hidden - after
all we are dealing with UI. without a container attached to the tag do
you now have to make those nonfunctional fragments of markup into
components so they can also be hidden?

 Also if we loose this coupling we can change java and html in a more
 independent way, resulting in more flexibility.

by losing coupling you also lose a lot of data - namely the nesting -
that is extremely useful in a lot of cases. eg - which form does this
textfield belong to?

 come up with a list of usecases where this is inconvenient and if
 there are a lot we can address them. but i cant really see many past
 Check/RadioGroup components.

^ too bad you have skipped that one :)



 When creating composite input fields (like date), the usual way is to
 create
 a panel even if you are not interested in reusability. A interesting
 aproach
 is to insert a hidden text field in HTML mapped to a component that
 controls
 other

Wicket feedback

2009-12-22 Thread Ricardo Mayerhofer


Hi all,
We've just finished with success a wicket project for a large online 
retailer. I think wicket is the best framework out there, but as any 
other project there is room for improvement. I will talk about some 
topics bellow, I hope it can help in some way.


- Separation of corcerns
I think we could get a better separation of concerns if page class were 
focused more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is 
to add behavior, and we have to add extra markup just to satisfy wicket 
1:1 mapping. Take CheckGroup for exaple, it is a component focused on 
behavior, even though we have to add a reference to it in HTML.


When creating composite input fields (like date), the usual way is to 
create a panel even if you are not interested in reusability. A 
interesting aproach is to insert a hidden text field in HTML mapped to a 
component that controls other components input. It makes easier to 
integrate with designer and to preview in browser. If we didn't have 
this limitation the hidden input would not be necessary and the 
development of behavior focused components would be easier.


One thing that bothers me is when our designer move things around in 
HTML and we get added a component in code but forgot to reference it in 
the markup error, because of component hierarchy. Html tags position is 
a view problem not a behavior problem, so why bother in java?


Another issue, is when we want to change the class of a div, for 
example, and have to change our whole page hierarchy in java, just to 
manipulate that tag.


So I think a hierarchy more focused on components behavior (for example 
taking care of inherited models and inputs), rather than tags position 
in HTML would be better. This would make wicket more flexible and easier 
to work with.


- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and 
unxepected situations its users may face in day to day development. 
Final modifiers places a additional challenge when facing these 
situations. In project were deadlines are in place, there is little room 
for submiting a request and waiting for a new version to be released. 
Furthermore, unfortunately, it's not possible to mock final methods 
making it harder sometimes to test wicket related classes/components. 
What we had to do internally, is to have our own version of wicket, 
mainly to remove final modifiers when necessary, a clear violation of 
open/closed principle.


- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes 
harder to integrate with a 3rd party ajax framework. Is there any hope 
for constructor change?


Please let me know your thoughts, keep up the good work.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket feedback



 +1 for last point Too many finals modifiers 
and subclassing isnt always better than listeners - My 2cents 



  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 6:49:02 PM
Subject: Wicket feedback

Hi all,
We've just finished with success a wicket project for a large online retailer. 
I think wicket is the best framework out there, but as any other project there 
is room for improvement. I will talk about some topics bellow, I hope it can 
help in some way.

- Separation of corcerns
I think we could get a better separation of concerns if page class were focused 
more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is to add 
behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
Take CheckGroup for exaple, it is a component focused on behavior, even though 
we have to add a reference to it in HTML.

When creating composite input fields (like date), the usual way is to create a 
panel even if you are not interested in reusability. A interesting aproach is 
to insert a hidden text field in HTML mapped to a component that controls other 
components input. It makes easier to integrate with designer and to preview in 
browser. If we didn't have this limitation the hidden input would not be 
necessary and the development of behavior focused components would be easier.

One thing that bothers me is when our designer move things around in HTML and 
we get added a component in code but forgot to reference it in the markup 
error, because of component hierarchy. Html tags position is a view problem not 
a behavior problem, so why bother in java?

Another issue, is when we want to change the class of a div, for example, and 
have to change our whole page hierarchy in java, just to manipulate that tag.

So I think a hierarchy more focused on components behavior (for example taking 
care of inherited models and inputs), rather than tags position in HTML would 
be better. This would make wicket more flexible and easier to work with.

- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and unxepected 
situations its users may face in day to day development. Final modifiers places 
a additional challenge when facing these situations. In project were deadlines 
are in place, there is little room for submiting a request and waiting for a 
new version to be released. Furthermore, unfortunately, it's not possible to 
mock final methods making it harder sometimes to test wicket related 
classes/components. What we had to do internally, is to have our own version of 
wicket, mainly to remove final modifiers when necessary, a clear violation of 
open/closed principle.

- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes harder 
to integrate with a 3rd party ajax framework. Is there any hope for constructor 
change?

Please let me know your thoughts, keep up the good work.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
http://in.yahoo.com/

Re: Wicket feedback

Ajax with wicket is easy.. if you do it the wicket way..  But integration with 
other engines isnt going to be easy.

Not only Ajax, from my little wicket experience, I would say wicket works great 
in isolation, however integrating it to any other framework would take (and it 
takes) comparatively more efforts.

 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 6:49:02 PM
Subject: Wicket feedback

Hi all,
We've just finished with success a wicket project for a large online retailer. 
I think wicket is the best framework out there, but as any other project there 
is room for improvement. I will talk about some topics bellow, I hope it can 
help in some way.

- Separation of corcerns
I think we could get a better separation of concerns if page class were focused 
more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is to add 
behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
Take CheckGroup for exaple, it is a component focused on behavior, even though 
we have to add a reference to it in HTML.

When creating composite input fields (like date), the usual way is to create a 
panel even if you are not interested in reusability. A interesting aproach is 
to insert a hidden text field in HTML mapped to a component that controls other 
components input. It makes easier to integrate with designer and to preview in 
browser. If we didn't have this limitation the hidden input would not be 
necessary and the development of behavior focused components would be easier.

One thing that bothers me is when our designer move things around in HTML and 
we get added a component in code but forgot to reference it in the markup 
error, because of component hierarchy. Html tags position is a view problem not 
a behavior problem, so why bother in java?

Another issue, is when we want to change the class of a div, for example, and 
have to change our whole page hierarchy in java, just to manipulate that tag.

So I think a hierarchy more focused on components behavior (for example taking 
care of inherited models and inputs), rather than tags position in HTML would 
be better. This would make wicket more flexible and easier to work with.

- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and unxepected 
situations its users may face in day to day development. Final modifiers places 
a additional challenge when facing these situations. In project were deadlines 
are in place, there is little room for submiting a request and waiting for a 
new version to be released. Furthermore, unfortunately, it's not possible to 
mock final methods making it harder sometimes to test wicket related 
classes/components. What we had to do internally, is to have our own version of 
wicket, mainly to remove final modifiers when necessary, a clear violation of 
open/closed principle.

- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes harder 
to integrate with a 3rd party ajax framework. Is there any hope for constructor 
change?

Please let me know your thoughts, keep up the good work.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
http://in.yahoo.com/

Re: Wicket feedback

On Tue, Dec 22, 2009 at 6:21 AM,  sudhir543-...@yahoo.com wrote:

lol

 Ajax with wicket is easy.. if you do it the wicket way..  But integration 
 with other engines isnt going to be easy.


maybe if you have little experience you should not be making such
sweeping statements. there are projects in wicketstuff and the
internets that integrate wicket with jquery, dojo, prototype, ricoh,
mootools, etc. and they do so easily, because wicket makes it easy.

 Not only Ajax, from my little wicket experience, I would say wicket works 
 great in isolation, however integrating it to any other framework would take 
 (and it takes) comparatively more efforts.

orly? so what about integrations with hibernate, jdo, jpa, spring,
guice, cdi, etc? i guess all those things are a figment of my
imagination.

-igor





 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 6:49:02 PM
 Subject: Wicket feedback

 Hi all,
 We've just finished with success a wicket project for a large online 
 retailer. I think wicket is the best framework out there, but as any other 
 project there is room for improvement. I will talk about some topics bellow, 
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were 
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to add 
 behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
 Take CheckGroup for exaple, it is a component focused on behavior, even 
 though we have to add a reference to it in HTML.

 When creating composite input fields (like date), the usual way is to create 
 a panel even if you are not interested in reusability. A interesting aproach 
 is to insert a hidden text field in HTML mapped to a component that controls 
 other components input. It makes easier to integrate with designer and to 
 preview in browser. If we didn't have this limitation the hidden input would 
 not be necessary and the development of behavior focused components would be 
 easier.

 One thing that bothers me is when our designer move things around in HTML and 
 we get added a component in code but forgot to reference it in the markup 
 error, because of component hierarchy. Html tags position is a view problem 
 not a behavior problem, so why bother in java?

 Another issue, is when we want to change the class of a div, for example, and 
 have to change our whole page hierarchy in java, just to manipulate that tag.

 So I think a hierarchy more focused on components behavior (for example 
 taking care of inherited models and inputs), rather than tags position in 
 HTML would be better. This would make wicket more flexible and easier to work 
 with.

 - Too many finals modifiers
 It's hard for a API or framework designer to foresee all uses and unxepected 
 situations its users may face in day to day development. Final modifiers 
 places a additional challenge when facing these situations. In project were 
 deadlines are in place, there is little room for submiting a request and 
 waiting for a new version to be released. Furthermore, unfortunately, it's 
 not possible to mock final methods making it harder sometimes to test wicket 
 related classes/components. What we had to do internally, is to have our own 
 version of wicket, mainly to remove final modifiers when necessary, a clear 
 violation of open/closed principle.

 - Ajax
 Wicket offers no stateless ajax and often changes HTML id, which makes harder 
 to integrate with a 3rd party ajax framework. Is there any hope for 
 constructor change?

 Please let me know your thoughts, keep up the good work.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
 http://in.yahoo.com/

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket feedback

2009-12-22 Thread Peter Thomas

On Tue, Dec 22, 2009 at 7:51 PM, sudhir543-...@yahoo.com wrote:

Ajax with wicket is easy.. if you do it the wicket way.. But integration
with other engines isnt going to be easy.

IMHO integration with other engines is actually quite easy, and certainly
far easier than other frameworks, see this:

http://ptrthomas.wordpress.com/2009/08/12/wicket-tutorial-yui-autocomplete-using-json-and-ajax/

in response to the OP who said:

- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes
harder to integrate with a 3rd party ajax framework. Is there any hope for
constructor change?

I haven't found this a problem in practice, maybe a smarter use of
getMarkupId() is the answer. BTW someone wrote a patch [1] to have stable
markup id-s, it was discussed on the list recently [2]:

[1]
http://blogs.onehippo.org/arthur/2009/02/hippoecm_integration_testing_w.html
[2]
http://old.nabble.com/Hippo%27s-patch-for-wicket-ids-ts25901638.html#a25901638

- Peter

Not only Ajax, from my little wicket experience, I would say wicket works
great in isolation, however integrating it to any other framework would take
(and it takes) comparatively more efforts.

Sudhir NimavatSenior software engineer.
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being
taught

From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 6:49:02 PM
Subject: Wicket feedback

Hi all,
We've just finished with success a wicket project for a large online
retailer. I think wicket is the best framework out there, but as any other
project there is room for improvement. I will talk about some topics bellow,
I hope it can help in some way.

- Separation of corcerns
I think we could get a better separation of concerns if page class were
focused more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is to
add behavior, and we have to add extra markup just to satisfy wicket 1:1
mapping. Take CheckGroup for exaple, it is a component focused on behavior,
even though we have to add a reference to it in HTML.

When creating composite input fields (like date), the usual way is to
create a panel even if you are not interested in reusability. A interesting
aproach is to insert a hidden text field in HTML mapped to a component that
controls other components input. It makes easier to integrate with designer
and to preview in browser. If we didn't have this limitation the hidden
input would not be necessary and the development of behavior focused
components would be easier.

One thing that bothers me is when our designer move things around in HTML
and we get added a component in code but forgot to reference it in the
markup error, because of component hierarchy. Html tags position is a view
problem not a behavior problem, so why bother in java?

Another issue, is when we want to change the class of a div, for example,
and have to change our whole page hierarchy in java, just to manipulate that
tag.

So I think a hierarchy more focused on components behavior (for example
taking care of inherited models and inputs), rather than tags position in
HTML would be better. This would make wicket more flexible and easier to
work with.

- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and
unxepected situations its users may face in day to day development. Final
modifiers places a additional challenge when facing these situations. In
project were deadlines are in place, there is little room for submiting a
request and waiting for a new version to be released. Furthermore,
unfortunately, it's not possible to mock final methods making it harder
sometimes to test wicket related classes/components. What we had to do
internally, is to have our own version of wicket, mainly to remove final
modifiers when necessary, a clear violation of open/closed principle.

- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes
harder to integrate with a 3rd party ajax framework. Is there any hope for
constructor change?

Please let me know your thoughts, keep up the good work.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/

Re: Wicket feedback

On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
ricardo.ekm.lis...@gmail.com wrote:
 Hi all,
 We've just finished with success a wicket project for a large online
 retailer. I think wicket is the best framework out there, but as any other
 project there is room for improvement. I will talk about some topics bellow,
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to
 add behavior, and we have to add extra markup just to satisfy wicket 1:1
 mapping. Take CheckGroup for exaple, it is a component focused on behavior,
 even though we have to add a reference to it in HTML.

a redesigned CheckGroup is welcome, but that component is the
exception and not the rule.

 When creating composite input fields (like date), the usual way is to create
 a panel even if you are not interested in reusability. A interesting aproach
 is to insert a hidden text field in HTML mapped to a component that controls
 other components input. It makes easier to integrate with designer and to
 preview in browser. If we didn't have this limitation the hidden input would
 not be necessary and the development of behavior focused components would be
 easier.

i dont really understand this..the usual way would be to extend a
FormComponentPanel, not a Panel. are you saying that because the Panel
derivatives are just a div in the markup it makes it difficult for
the designers?

 One thing that bothers me is when our designer move things around in HTML
 and we get added a component in code but forgot to reference it in the
 markup error, because of component hierarchy. Html tags position is a view
 problem not a behavior problem, so why bother in java?

it *is* a behavior problem. markup is what drives the rendering order
so if you move things around and change the nesting order of
components then you can have a component that is a child of another
render *before* the parent which will cause things to go seriously out
of whack.

in my company the designers understand that they cannot change the
nesting of tags with wicket:id attributes, it took an hour to explain
it to them, and we have not had any problems since. in practice, there
is no need to do that often anyways...


 Another issue, is when we want to change the class of a div, for example,
 and have to change our whole page hierarchy in java, just to manipulate that
 tag.

you dont have to change the hierarchy, just make the component
attached to that div a transparent resolver by overriding
isTransparentResolver() and returning true.

 So I think a hierarchy more focused on components behavior (for example
 taking care of inherited models and inputs), rather than tags position in
 HTML would be better. This would make wicket more flexible and easier to
 work with.

once again, this is only a problem when you change the *nesting* of
components. if a component can be safely moved outside the parent,
then why is there a nesting to begin with? why arent the two
components siblings? the *nesting* is usually there *because* there is
a functional requirement.

here is a simple usecase:

webmarkupcontainer admin=new webmarkupcontainer(admin) { isvisible()
{ return user.isadmin(); }};
admin.add(new link(delete) {...});

the code is pretty much self-explanatory, now the designer takes the
delete link and moves it ouside the wicket:id=admin tag. in your
vision this would work, but now the designer has completely
circumvented security the developer has put into place.

 - Too many finals modifiers
 It's hard for a API or framework designer to foresee all uses and unxepected
 situations its users may face in day to day development. Final modifiers
 places a additional challenge when facing these situations. In project were
 deadlines are in place, there is little room for submiting a request and
 waiting for a new version to be released. Furthermore, unfortunately, it's
 not possible to mock final methods making it harder sometimes to test wicket
 related classes/components. What we had to do internally, is to have our own
 version of wicket, mainly to remove final modifiers when necessary, a clear
 violation of open/closed principle.

there is a trade off here. the final modifiers allow us to change
things below without breaking the api because final methods do not
expose a contract. when we make a code change inside a final method we
do not have to think about all the users out there who might have
potentially overridden the method in their apps and we have to make
whatever change backwards-compatible.

in short, the upgrade path with final methods looks like this:

1.4.0,1.4.1,...,1.4.8,1.4.9

and the path without final methods would look like this:

1.4.0,1.4.1,1.5.0 (api break),1.5.1, 1.6.0 (api break), 1.7.0 (api break)

and because we are changing contracts the

Re: Wicket feedback

Yes, from my little experience, I just started learning it [Because I feel it 
has some thing different to offer]

orly? so what about integrations with hibernate, jdo, jpa, spring,
guice, cdi, etc? i guess all those things are a figment of my
imagination.

As I said it takes comparatively(to some others) more efforts. 
If I talk about spring, using spring with wicket needs special care, one will 
have to take care that he does not serialize entire containers. I haven't  
tried to use hibernate yet (just playing with inmemories) but I think that I 
will have to create LoadableDetachable model of most of my entities (plz 
correct me if I am wrong)



 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 9:46:45 PM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 6:21 AM,  sudhir543-...@yahoo.com wrote:

lol

 Ajax with wicket is easy.. if you do it the wicket way..  But integration 
 with other engines isnt going to be easy.


maybe if you have little experience you should not be making such
sweeping statements. there are projects in wicketstuff and the
internets that integrate wicket with jquery, dojo, prototype, ricoh,
mootools, etc. and they do so easily, because wicket makes it easy.

 Not only Ajax, from my little wicket experience, I would say wicket works 
 great in isolation, however integrating it to any other framework would take 
 (and it takes) comparatively more efforts.

orly? so what about integrations with hibernate, jdo, jpa, spring,
guice, cdi, etc? i guess all those things are a figment of my
imagination.

-igor





 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 6:49:02 PM
 Subject: Wicket feedback

 Hi all,
 We've just finished with success a wicket project for a large online 
 retailer. I think wicket is the best framework out there, but as any other 
 project there is room for improvement. I will talk about some topics bellow, 
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were 
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to add 
 behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
 Take CheckGroup for exaple, it is a component focused on behavior, even 
 though we have to add a reference to it in HTML.

 When creating composite input fields (like date), the usual way is to create 
 a panel even if you are not interested in reusability. A interesting aproach 
 is to insert a hidden text field in HTML mapped to a component that controls 
 other components input. It makes easier to integrate with designer and to 
 preview in browser. If we didn't have this limitation the hidden input would 
 not be necessary and the development of behavior focused components would be 
 easier.

 One thing that bothers me is when our designer move things around in HTML and 
 we get added a component in code but forgot to reference it in the markup 
 error, because of component hierarchy. Html tags position is a view problem 
 not a behavior problem, so why bother in java?

 Another issue, is when we want to change the class of a div, for example, and 
 have to change our whole page hierarchy in java, just to manipulate that tag.

 So I think a hierarchy more focused on components behavior (for example 
 taking care of inherited models and inputs), rather than tags position in 
 HTML would be better. This would make wicket more flexible and easier to work 
 with.

 - Too many finals modifiers
 It's hard for a API or framework designer to foresee all uses and unxepected 
 situations its users may face in day to day development. Final modifiers 
 places a additional challenge when facing these situations. In project were 
 deadlines are in place, there is little room for submiting a request and 
 waiting for a new version to be released. Furthermore, unfortunately, it's 
 not possible to mock final methods making it harder sometimes to test wicket 
 related classes/components. What we had to do internally, is to have our own 
 version of wicket, mainly to remove final modifiers when necessary, a clear 
 violation of open/closed principle.

 - Ajax
 Wicket offers no stateless ajax and often changes HTML id, which makes harder 
 to integrate with a 3rd party ajax framework. Is there any hope for 
 constructor change?

 Please let me

Re: Wicket feedback

On Tue, Dec 22, 2009 at 10:20 AM,  sudhir543-...@yahoo.com wrote:
 Yes, from my little experience, I just started learning it [Because I feel it 
 has some thing different to offer]

orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 As I said it takes comparatively(to some others) more efforts.
 If I talk about spring, using spring with wicket needs special care, one will 
 have to take care that he  does not serialize entire containers.

that is taken care for you by the framework. all you have to do is
install the component injector (1 line of code) and use @SpringBean
annotations in your pages to inject your dependencies. show me a
framework that makes this easier...

I haven't  tried to use hibernate yet (just playing with inmemories) but I 
think that I will have to  create LoadableDetachable model of most of my 
entities (plz correct me if I am wrong)

LDMs have nothing to do with integration with other frameworks but how
you want to manage state. in some cases it makes sense not to use LDMs
for hibernate entities.

-igor








 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 9:46:45 PM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 6:21 AM,  sudhir543-...@yahoo.com wrote:

 lol

 Ajax with wicket is easy.. if you do it the wicket way..  But integration 
 with other engines isnt going to be easy.


 maybe if you have little experience you should not be making such
 sweeping statements. there are projects in wicketstuff and the
 internets that integrate wicket with jquery, dojo, prototype, ricoh,
 mootools, etc. and they do so easily, because wicket makes it easy.

 Not only Ajax, from my little wicket experience, I would say wicket works 
 great in isolation, however integrating it to any other framework would take 
 (and it takes) comparatively more efforts.

 orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 -igor





 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 6:49:02 PM
 Subject: Wicket feedback

 Hi all,
 We've just finished with success a wicket project for a large online 
 retailer. I think wicket is the best framework out there, but as any other 
 project there is room for improvement. I will talk about some topics bellow, 
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were 
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to 
 add behavior, and we have to add extra markup just to satisfy wicket 1:1 
 mapping. Take CheckGroup for exaple, it is a component focused on behavior, 
 even though we have to add a reference to it in HTML.

 When creating composite input fields (like date), the usual way is to create 
 a panel even if you are not interested in reusability. A interesting aproach 
 is to insert a hidden text field in HTML mapped to a component that controls 
 other components input. It makes easier to integrate with designer and to 
 preview in browser. If we didn't have this limitation the hidden input would 
 not be necessary and the development of behavior focused components would be 
 easier.

 One thing that bothers me is when our designer move things around in HTML 
 and we get added a component in code but forgot to reference it in the 
 markup error, because of component hierarchy. Html tags position is a view 
 problem not a behavior problem, so why bother in java?

 Another issue, is when we want to change the class of a div, for example, 
 and have to change our whole page hierarchy in java, just to manipulate that 
 tag.

 So I think a hierarchy more focused on components behavior (for example 
 taking care of inherited models and inputs), rather than tags position in 
 HTML would be better. This would make wicket more flexible and easier to 
 work with.

 - Too many finals modifiers
 It's hard for a API or framework designer to foresee all uses and unxepected 
 situations its users may face in day to day development. Final modifiers 
 places a additional challenge when facing these situations. In project were 
 deadlines are in place, there is little room for submiting a request and 
 waiting for a new version to be released

Re: Wicket feedback

Thanks for clarifying the things,

 show me a framework that makes this easier... 
I think that when I when I was working with Webwork (Struts2 now) I dint need 
to do any thing else other than specifying spring factory in one of config 
file. Neither I was forced to use annotations.


LDMA might have nothing to do with Integration, but from my lil experience, I 
think that When I want to pass my entity as a model to some components (which 
might be serialized as in most cases) It wouldnt work with normal models, I 
will have to manage a separate LDM class for each of that if I don't want 
lazyloading exceptions. 


 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 12:03:05 AM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 10:20 AM,  sudhir543-...@yahoo.com wrote:
 Yes, from my little experience, I just started learning it [Because I feel it 
 has some thing different to offer]

orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 As I said it takes comparatively(to some others) more efforts.
 If I talk about spring, using spring with wicket needs special care, one will 
 have to take care that he  does not serialize entire containers.

that is taken care for you by the framework. all you have to do is
install the component injector (1 line of code) and use @SpringBean
annotations in your pages to inject your dependencies. show me a
framework that makes this easier...

I haven't  tried to use hibernate yet (just playing with inmemories) but I 
think that I will have to  create LoadableDetachable model of most of my 
entities (plz correct me if I am wrong)

LDMs have nothing to do with integration with other frameworks but how
you want to manage state. in some cases it makes sense not to use LDMs
for hibernate entities.

-igor








 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 9:46:45 PM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 6:21 AM,  sudhir543-...@yahoo.com wrote:

 lol

 Ajax with wicket is easy.. if you do it the wicket way..  But integration 
 with other engines isnt going to be easy.


 maybe if you have little experience you should not be making such
 sweeping statements. there are projects in wicketstuff and the
 internets that integrate wicket with jquery, dojo, prototype, ricoh,
 mootools, etc. and they do so easily, because wicket makes it easy.

 Not only Ajax, from my little wicket experience, I would say wicket works 
 great in isolation, however integrating it to any other framework would take 
 (and it takes) comparatively more efforts.

 orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 -igor





 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 6:49:02 PM
 Subject: Wicket feedback

 Hi all,
 We've just finished with success a wicket project for a large online 
 retailer. I think wicket is the best framework out there, but as any other 
 project there is room for improvement. I will talk about some topics bellow, 
 I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were 
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to 
 add behavior, and we have to add extra markup just to satisfy wicket 1:1 
 mapping. Take CheckGroup for exaple, it is a component focused on behavior, 
 even though we have to add a reference to it in HTML.

 When creating composite input fields (like date), the usual way is to create 
 a panel even if you are not interested in reusability. A interesting aproach 
 is to insert a hidden text field in HTML mapped to a component that controls 
 other components input. It makes easier to integrate with designer and to 
 preview in browser. If we didn't have this limitation the hidden input would 
 not be necessary and the development of behavior focused components would be 
 easier.

 One thing that bothers me is when our designer move things

Re: Wicket feedback

On Tue, Dec 22, 2009 at 11:13 AM,  sudhir543-...@yahoo.com wrote:
 Thanks for clarifying the things,

 show me a framework that makes this easier...
 I think that when I when I was working with Webwork (Struts2 now) I dint need 
 to do any thing else other than specifying spring factory in one of config 
 file. Neither I was forced to use annotations.

so how does webwork know which properties of your actions should be
injected from spring and which from the request or session objects?

 LDMA might have nothing to do with Integration, but from my lil experience, I 
 think that When I want to pass my entity as a model to some components (which 
 might be serialized as in most cases) It wouldnt work with normal models, I 
 will have to manage a separate LDM class for each of that if I don't want 
 lazyloading exceptions.

huh? it all depends on how your domain model works. every application
is different. same applies to other frameworks - eg when you need to
put your entity into session because you want to access it across
requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for
dealing with these kinds of issues.

-igor






 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Wed, 23 December, 2009 12:03:05 AM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 10:20 AM,  sudhir543-...@yahoo.com wrote:
 Yes, from my little experience, I just started learning it [Because I feel 
 it has some thing different to offer]

orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 As I said it takes comparatively(to some others) more efforts.
 If I talk about spring, using spring with wicket needs special care, one 
 will have to take care that he  does not serialize entire containers.

 that is taken care for you by the framework. all you have to do is
 install the component injector (1 line of code) and use @SpringBean
 annotations in your pages to inject your dependencies. show me a
 framework that makes this easier...

I haven't  tried to use hibernate yet (just playing with inmemories) but I 
think that I will have to  create LoadableDetachable model of most of my 
entities (plz correct me if I am wrong)

 LDMs have nothing to do with integration with other frameworks but how
 you want to manage state. in some cases it makes sense not to use LDMs
 for hibernate entities.

 -igor








 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 9:46:45 PM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 6:21 AM,  sudhir543-...@yahoo.com wrote:

 lol

 Ajax with wicket is easy.. if you do it the wicket way..  But integration 
 with other engines isnt going to be easy.


 maybe if you have little experience you should not be making such
 sweeping statements. there are projects in wicketstuff and the
 internets that integrate wicket with jquery, dojo, prototype, ricoh,
 mootools, etc. and they do so easily, because wicket makes it easy.

 Not only Ajax, from my little wicket experience, I would say wicket works 
 great in isolation, however integrating it to any other framework would 
 take (and it takes) comparatively more efforts.

 orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 -igor





 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 6:49:02 PM
 Subject: Wicket feedback

 Hi all,
 We've just finished with success a wicket project for a large online 
 retailer. I think wicket is the best framework out there, but as any other 
 project there is room for improvement. I will talk about some topics 
 bellow, I hope it can help in some way.

 - Separation of corcerns
 I think we could get a better separation of concerns if page class were 
 focused more in behavior and html were more focused in display (or view).
 What I mean is, some times we have components that the main purpose is to 
 add behavior, and we have to add extra markup just to satisfy wicket 1:1 
 mapping. Take CheckGroup for exaple, it is a component focused

Re: Wicket feedback

 so how does webwork know which properties of your actions should be injected 
 from spring and which from the request or session objects?

- Actions can be configured as spring beans... webwork knows how to get it from 
there, developer decides what dependencies should be managed by spring.
- Action is available in valuestack, for example, when form is submitted, 
webwork can set properties directly on your action or on your model if it is a 
  modal driven action. Interceptors does this. 

it all depends on how your domain model works
Sorry, but I don't get how LDM depends on domain model.. I belive by domain 
model you mean, the core 'domain model design' of application. Entities and 
relationships ?

 when you need to put your entity into session because you want to access it 
 acrossrequests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for dealing 
with these kinds of issues.

During most of my past project, I was rarely if ever required to put entities 
into session, most of the time alternatives worked. 
Wicket requires me to put entities into session and so provides LDM. So its 
like a solution to its own need.

I can understand that being a component oriented framework, wicket has lil 
different needs, and thts fine most of time. 
My point was 'there's some overhead involved when working on integration of 
other frameworks'.

Thanks
SN




Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 2:13:37 AM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 11:13 AM,  sudhir543-...@yahoo.com wrote:
 Thanks for clarifying the things,

 show me a framework that makes this easier...
 I think that when I when I was working with Webwork (Struts2 now) I dint need 
 to do any thing else other than specifying spring factory in one of config 
 file. Neither I was forced to use annotations.

so how does webwork know which properties of your actions should be
injected from spring and which from the request or session objects?

 LDMA might have nothing to do with Integration, but from my lil experience, I 
 think that When I want to pass my entity as a model to some components (which 
 might be serialized as in most cases) It wouldnt work with normal models, I 
 will have to manage a separate LDM class for each of that if I don't want 
 lazyloading exceptions.

huh? it all depends on how your domain model works. every application
is different. same applies to other frameworks - eg when you need to
put your entity into session because you want to access it across
requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for
dealing with these kinds of issues.

-igor






 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Wed, 23 December, 2009 12:03:05 AM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 10:20 AM,  sudhir543-...@yahoo.com wrote:
 Yes, from my little experience, I just started learning it [Because I feel 
 it has some thing different to offer]

orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 As I said it takes comparatively(to some others) more efforts.
 If I talk about spring, using spring with wicket needs special care, one 
 will have to take care that he  does not serialize entire containers.

 that is taken care for you by the framework. all you have to do is
 install the component injector (1 line of code) and use @SpringBean
 annotations in your pages to inject your dependencies. show me a
 framework that makes this easier...

I haven't  tried to use hibernate yet (just playing with inmemories) but I 
think that I will have to  create LoadableDetachable model of most of my 
entities (plz correct me if I am wrong)

 LDMs have nothing to do with integration with other frameworks but how
 you want to manage state. in some cases it makes sense not to use LDMs
 for hibernate entities.

 -igor








 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Tue, 22 December, 2009 9:46:45 PM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 6:21 AM

Re: Wicket feedback

2009-12-22 Thread Sudhir N

One more thing I am still looking for is, integrating GWT. I did that before 
with other framework. 


 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: sudhir543-...@yahoo.com sudhir543-...@yahoo.com
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 11:57:34 AM
Subject: Re: Wicket feedback


 so how does webwork know which properties of your actions should be injected 
 from spring and which from the request or session objects?

- Actions can be configured as spring beans... webwork knows how to get it from 
there, developer decides what dependencies should be managed by spring.
- Action is available in valuestack, for example, when form is submitted, 
webwork can set properties directly on your action or on your model if it is a 
  modal driven action. Interceptors does this. 

it all depends on how your domain model works
Sorry, but I don't get how LDM depends on domain model.. I belive by domain 
model you mean, the core 'domain model design' of application. Entities and 
relationships ?

 when you need to put your entity into session because you want to access it 
 across requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for dealing 
with these kinds of issues.

During most of my past project, I was rarely if ever required to put entities 
into session, most of the time alternatives worked. 
Wicket requires me to put entities into session and so provides LDM. So its 
like a solution to its own need.

I can understand that being a component oriented framework, wicket has lil 
different needs, and thts fine most of time. 
My point was 'there's some overhead involved when working on integration of 
other frameworks'.

Thanks
SN




Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 2:13:37 AM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 11:13 AM,  sudhir543-...@yahoo.com wrote:
 Thanks for clarifying the things,

 show me a framework that makes this easier...
 I think that when I when I was working with Webwork (Struts2 now) I dint need 
 to do any thing else other than specifying spring factory in one of config 
 file. Neither I was forced to use annotations.

so how does webwork know which properties of your actions should be
injected from spring and which from the request or session objects?

 LDMA might have nothing to do with Integration, but from my lil experience, I 
 think that When I want to pass my entity as a model to some components (which 
 might be serialized as in most cases) It wouldnt work with normal models, I 
 will have to manage a separate LDM class for each of that if I don't want 
 lazyloading exceptions.

huh? it all depends on how your domain model works. every application
is different. same applies to other frameworks - eg when you need to
put your entity into session because you want to access it across
requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for
dealing with these kinds of issues.

-igor






 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Wed, 23 December, 2009 12:03:05 AM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 10:20 AM,  sudhir543-...@yahoo.com wrote:
 Yes, from my little experience, I just started learning it [Because I feel 
 it has some thing different to offer]

orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 As I said it takes comparatively(to some others) more efforts.
 If I talk about spring, using spring with wicket needs special care, one 
 will have to take care that he  does not serialize entire containers.

 that is taken care for you by the framework. all you have to do is
 install the component injector (1 line of code) and use @SpringBean
 annotations in your pages to inject your dependencies. show me a
 framework that makes this easier...

I haven't  tried to use hibernate yet (just playing with inmemories) but I 
think that I will have to  create LoadableDetachable model of most of my 
entities (plz correct me if I am wrong)

 LDMs have nothing to do with integration with other frameworks but how
 you want to manage state. in some

Re: Wicket feedback

On Tue, Dec 22, 2009 at 10:27 PM,  sudhir543-...@yahoo.com wrote:
 so how does webwork know which properties of your actions should be injected 
 from spring and which from the request or session objects?

 - Actions can be configured as spring beans... webwork knows how to get it 
 from there, developer decides what dependencies should be managed by spring.
 - Action is available in valuestack, for example, when form is submitted, 
 webwork can set properties directly on your action or on your model if it is a
  modal driven action. Interceptors does this.


well, so much for your single line of code is all it takes, since
you also have to declare each action in spring's xml. or if you use
their new approach you get to put..wait for it..annotations into your
actions such as @Component and @Autowired. wicket's @SpringBean is
analogous to @Autowired.

it all depends on how your domain model works
 Sorry, but I don't get how LDM depends on domain model.. I belive by domain 
 model you mean, the core 'domain model design' of application. Entities and 
 relationships ?

some domain models are designed with serialization in mind. they make
it easy to take any domain object and safely serialize it, then at a
later time merge the changes using eg entitymanager.merge(entity).

others are not. their objects do not support serialization. these
models depend on some kind of dtos to allow mutation.

 when you need to put your entity into session because you want to access it 
 acrossrequests, or when you put things into conversation scope. this problem
 has nothing to do with wicket. LDM is simply one concrete solution for 
 dealing with these kinds of issues.

 During most of my past project, I was rarely if ever required to put entities 
 into session, most of the time alternatives worked.
 Wicket requires me to put entities into session and so provides LDM. So its 
 like a solution to its own need.

no, you are welcome to use alternatives, such as dtos.

 I can understand that being a component oriented framework, wicket has lil 
 different needs, and thts fine most of time.
 My point was 'there's some overhead involved when working on integration of 
 other frameworks'.

yeah, i still dont see any of this overhead. LDM has nothing to do
with integration of other frameworks anyways.

-igor


 Thanks
 SN




 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Wed, 23 December, 2009 2:13:37 AM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 11:13 AM,  sudhir543-...@yahoo.com wrote:
 Thanks for clarifying the things,

 show me a framework that makes this easier...
 I think that when I when I was working with Webwork (Struts2 now) I dint 
 need to do any thing else other than specifying spring factory in one of 
 config file. Neither I was forced to use annotations.

 so how does webwork know which properties of your actions should be
 injected from spring and which from the request or session objects?

 LDMA might have nothing to do with Integration, but from my lil experience, 
 I think that When I want to pass my entity as a model to some components 
 (which might be serialized as in most cases) It wouldnt work with normal 
 models, I will have to manage a separate LDM class for each of that if I 
 don't want lazyloading exceptions.

 huh? it all depends on how your domain model works. every application
 is different. same applies to other frameworks - eg when you need to
 put your entity into session because you want to access it across
 requests, or when you put things into conversation scope. this problem
 has nothing to do with wicket. LDM is simply one concrete solution for
 dealing with these kinds of issues.

 -igor






 Sudhir NimavatSenior software engineer.
 Quick start global PVT LTD.
 Baroda - 390007
 Gujarat, India

 Personally I'm always ready to learn, although I do not always like being 
 taught





 
 From: Igor Vaynberg igor.vaynb...@gmail.com
 To: users@wicket.apache.org
 Sent: Wed, 23 December, 2009 12:03:05 AM
 Subject: Re: Wicket feedback

 On Tue, Dec 22, 2009 at 10:20 AM,  sudhir543-...@yahoo.com wrote:
 Yes, from my little experience, I just started learning it [Because I feel 
 it has some thing different to offer]

orly? so what about integrations with hibernate, jdo, jpa, spring,
 guice, cdi, etc? i guess all those things are a figment of my
 imagination.

 As I said it takes comparatively(to some others) more efforts.
 If I talk about spring, using spring with wicket needs special care, one 
 will have to take care that he  does not serialize entire containers.

 that is taken care for you by the framework. all you have to do is
 install the component injector (1 line of code) and use

Re: Wicket feedback