wicketstuff-animator for Wicket 1.4?
Hello, I would like to try out wicketstuff-animator but when trying out the basic example on the official page (http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator) with wicket 1.4.4 I get an exception. I guess it's because wicketstuff-animator depends on wicket 1.3.3? I'm using wicketstuff-animator 1.3.3 fond here: http://www.wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-animator/1.3.3-SNAPSHOT/. Is there a way to make it work for wicket 1.4 or does anyone know when/if a 1.4-compatible version will be released? The exception I get is: WicketMessage: Can't instantiate page using constructor public com.test.wicket.page.TimeReporterPage() Root cause: java.lang.NoSuchMethodError: org.apache.wicket.Component.add(Lorg/apache/wicket/behavior/IBehavior;)Lorg/apache/wicket/Component; at org.wicketstuff.animator.Animator.attachTo(Animator.java:493) at com.test.wicket.page.TimeReporterPage.init(TimeReporterPage.java:54) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:192) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:57) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:299) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1241) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1320) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1419) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:289) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:295) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:361) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) Complete stack: org.apache.wicket.WicketRuntimeException: Can't instantiate page using constructor public com.test.wicket.page.TimeReporterPage() at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:212) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:57) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:299) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1241) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1320) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1419) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:192) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:57) at
Re: Wicket feedback
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
vision this would work, but now the designer has completely
circumvented security the developer has put into place.
They have a functional relationship, so no matter where delete link is
in HTML, it should be invisible. This has a aditional advantage that I
do not need to map admin
Re: Wicket feedback
Take a look at HibernateObjectModel from databinder project. 2009/12/22 sudhir543-...@yahoo.com: 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
Re: Wicket feedback
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
vision this would work, but now the designer has completely
circumvented security the developer has put into place.
They have a
Re: Wicket feedback
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?
Re: Wicket feedback
an interesting question... i had some thoughts about this as related to my sprockets experiment a few years back... http://mail-archives.apache.org/mod_mbox/wicket-users/200804.mbox/%3c16411092.p...@talk.nabble.com%3e unfortunately, i know as little about GWT now as i did then. jon On Dec 23, 2009, at 7:38 AM, Johan Compagner 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
Multi-user environment problem
Hi,
I'm having a problem with a multi-user environment. I have a form, which
has an edit button. When a user presses the edit button, I write to the
database that this current user is editing the form. So when another
user comes along and wants to edit it, he gets the message that the form
cannot be edited because it's locked by another user. This works fine
when user A loads the form, presses the edit button and after that user
B comes along. However, if the process is: user A comes along and loads
the form, user B loads the same form, then user A presses the edit
button and after that user B presses it. Then I get an unexpected
runtimeexception and the message:
WicketMessage: Submit Button topBar:edit (path=arfForm:topBar:edit) is
not visible
Now this obviously has to do with the way I'm determining whether or not
this button should be visible. What I did is extend the Button class and
override the isVisible method. Here I check whether there is no editor,
if so, the button should be visible so the current user can become the
editor. However, since in this situation, user B became the editor while
this user had already loaded the form, the button is no longer valid for
user A but he already has it on his screen. I thought to check this in
the onSubmit method and retrieve the persisted object and check if
nothing had changed in the meantime, but apparently Wicket checks
whether this button should have been visible in the first place. And
since I use LoadableDetachableModel as the underlying model (arfModel)
the updated object is retrieved and Wicket detects that the isVisible
method returns false and throws an error that I'm trying to call the
onSubmit method.
Does anyone know of an elegant solution for this problem? Please see
below for my implementation of the edit button.
Thanks, Jonck
add(new Button(edit) {
@Override
public void onSubmit() {
String username =
((AppAuthenticatedWebSession)getSession()).getUsername();
ARF currentArf = arfModel.getObject();
ARF persistedArf = arfService.load(currentArf.getId());
if (persistedArf.getEditor() == null ||
persistedArf.getEditor().equals(username)) {
currentArf.setEditor(username);
arfService.save(currentArf);
}
}
@Override
public boolean isVisible() {
String editor = arfModel.getObject().getEditor();
if (editor == null) {
return true;
}
return false;
}
});
Palette: how to track which entries in either choices element are selected?
For some very special usecase I need a Palette which allows me to track via Ajax which entries in either choices element are selected as long as I have not submitted the form. Just to clarify things: 'selected' in this context does not denote the elements in the 'selected' choices element but those options which the user has selected (with the mouse or keyboard). I tried to find out in the debugger how this all works, but it seems like there's quite a bit of Javascript involved. Maybe someone out there has already solved this problem and may help me out with some hint? Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Man moechte ja lieber Auslaender sein als gieriges kleines Inlaenderschwein, doch wo das eine nicht geht, da faengt das andere an, und das Problem ist, dass man wo man ist nichts anderes sein kann... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Multi-user environment problem
Override isEnabled instead. That way it is visible, even after being
clicked when the other person clicked it first. You may have to add some
logic in the onClick that says oops - already in use.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Dec 23, 2009 at 9:46 AM, Kogel, Jonck-van-der
jonck-van-der.ko...@bmw.nl wrote:
Hi,
I'm having a problem with a multi-user environment. I have a form, which
has an edit button. When a user presses the edit button, I write to the
database that this current user is editing the form. So when another
user comes along and wants to edit it, he gets the message that the form
cannot be edited because it's locked by another user. This works fine
when user A loads the form, presses the edit button and after that user
B comes along. However, if the process is: user A comes along and loads
the form, user B loads the same form, then user A presses the edit
button and after that user B presses it. Then I get an unexpected
runtimeexception and the message:
WicketMessage: Submit Button topBar:edit (path=arfForm:topBar:edit) is
not visible
Now this obviously has to do with the way I'm determining whether or not
this button should be visible. What I did is extend the Button class and
override the isVisible method. Here I check whether there is no editor,
if so, the button should be visible so the current user can become the
editor. However, since in this situation, user B became the editor while
this user had already loaded the form, the button is no longer valid for
user A but he already has it on his screen. I thought to check this in
the onSubmit method and retrieve the persisted object and check if
nothing had changed in the meantime, but apparently Wicket checks
whether this button should have been visible in the first place. And
since I use LoadableDetachableModel as the underlying model (arfModel)
the updated object is retrieved and Wicket detects that the isVisible
method returns false and throws an error that I'm trying to call the
onSubmit method.
Does anyone know of an elegant solution for this problem? Please see
below for my implementation of the edit button.
Thanks, Jonck
add(new Button(edit) {
@Override
public void onSubmit() {
String username =
((AppAuthenticatedWebSession)getSession()).getUsername();
ARF currentArf = arfModel.getObject();
ARF persistedArf = arfService.load(currentArf.getId());
if (persistedArf.getEditor() == null ||
persistedArf.getEditor().equals(username)) {
currentArf.setEditor(username);
arfService.save(currentArf);
}
}
@Override
public boolean isVisible() {
String editor = arfModel.getObject().getEditor();
if (editor == null) {
return true;
}
return false;
}
});
Re: 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
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
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: [OT a wee bit] Happy Holidays Wicketeers!
Merry X-Mas Happy holidays and a very Wickety new year, may it bring many new stuffings and wicket features. From Frederikssund Denmark :) 2009/12/23 Jens Greven j...@greven.org: Steve Hiller schrieb: I just want to take this opportunity to thank all the Wicketeers who have been very kind to me over the past couple of years by 1) creating the Wicket framework and 2) providing generous support. The company I work for now has several enterprise-wise apps based on Wicket, all of which are considered true success stories. Once again, thanks and Happy Holidays to you all. Steve Merry X-Mas, Happy holidays and a very good new year 2010 to everyone in this supportive community from Muenster, Germany, too ;-) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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
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
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: Palette: how to track which entries in either choices element are selected?
From a very vague memory, it has a delimited number of choices in a string or something (in java script).. 2009/12/23 Martin Dietze d...@fh-wedel.de: For some very special usecase I need a Palette which allows me to track via Ajax which entries in either choices element are selected as long as I have not submitted the form. Just to clarify things: 'selected' in this context does not denote the elements in the 'selected' choices element but those options which the user has selected (with the mouse or keyboard). I tried to find out in the debugger how this all works, but it seems like there's quite a bit of Javascript involved. Maybe someone out there has already solved this problem and may help me out with some hint? Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Man moechte ja lieber Auslaender sein als gieriges kleines Inlaenderschwein, doch wo das eine nicht geht, da faengt das andere an, und das Problem ist, dass man wo man ist nichts anderes sein kann... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 1.4-rc6 Swarm
Hi Olivier, Till now, I kept it up to date till 1.4.3 based on snapshots. I ran into trouble with the build system and could figure out how to get that working. In the last few weeks a new version of TeamCity was installed. I'll give it another try and figure out how to create a release. We use the SNAPSHOTS in production without issues, so it should be no problem. Otherwise drop a mail. Kind Regards, Olger On 22 dec 2009, at 16:01, Olivier Bourgeois wrote: Is there any news regarding a release of Swarm 1.4 ? Because there's still only the 1.4 snapshots in the repository. For information, I'm currently using it with Wicket 1.4.3 and got no problem so far : page security and component conditional rendering works fine. 2009/7/10 Luca Provenzani eufor...@gmail.com this is a very good new! thank you a lot! Luca 2009/7/9 Olger Warnier ol...@xs4all.nl Hi Igor / List, Thanks for the trust. The wicket-security project trunk found at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-securityis now compatible with wicket 1.4 RC6. If you have issues or comments, please let me know. I am not aware of your release rules, if you have a pointer, I could check if it is possibe to get it towards a release along with the wicket 1.4 release. Kind Regards, Olger - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket feedback
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: Palette: how to track which entries in either choices element are selected?
On Wed, December 23, 2009, nino martinez wael wrote: From a very vague memory, it has a delimited number of choices in a string or something (in java script).. Yes, there's a lot of JS stuff involved. But since the Choices class is a FormComponent, should I not - if I attach an OnChangeAjaxBehaviour to the component - be able to get the selected option(s)? I mean, the OnChangeAjaxBehaviour performs all the actions which would normally be performed at form submit, so in principle I should be able to get access to this information without having to fiddle with Javascript, or am I wrong? I already subclassed Choices to add some of my own custom stuff, so I could as well set a default model and implement things like updateModel() and convertInput(), but having done so I find myself unable to find out how to set the right stuff in my code, the request parameters do not seem to contain anything usable... Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Was ist ein Cluster? Wenn vier Bratscher unisono spielen. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to post form to new window using AjaxSubmitLink
Thanks Igor and Zak, that worked for what I needed. I'd still prefer to be
able to post the form data to the new window, but I'm able to get around
form post using the query string for now.
I also encountered the issue with the name for the window in IE. Looks like
spaces also cause the problem. I found that 'null' works or just an alpha
string with no spaces.
Thanks again for the help.
Zak Johnson-2 wrote:
I had a similar need and did as Igor suggested. Here is an example:
add(new AjaxButton(ajax-button){
public void onSubmit(AjaxRequestTarget target, Form form) {
...create result page, get the url path to it...
target.appendJavascript(window.open('http://page_path_goes_here
','window_name'););
}
});
Something funny i'm working through in testing (and this a javascript
issue,
not wicket) is that IE won't open the window unless the window name is
strictly alpha-numeric. FF works fine though.
Zak
On Fri, Dec 11, 2009 at 2:50 PM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
you can output some javascript using the ajaxrequesttarget that does
window.open
-igor
On Fri, Dec 11, 2009 at 12:31 PM, Jeff Andersen jander...@posportal.com
wrote:
I need to know how I can post a form to a new window using an
AjaxSubmitLink. I have a small page where a user can make a few setting
changes and then either save those settings (using an AjaxButton) or
preview
those settings (using an AjaxSubmitLink) in a new window. The problem
is, I
can't figure out how to make the preview button open in a new window.
Since
there are no popup settings for an AjaxSubmitLink, I'm not sure what to
do.
I've tried searching for a solution and the best I could find indicated
that I should use a form target=_blank. But that doesn't seem to
change
anything. The call to setResponsePage always results in the preview page
opening in the same browser window.
Below is the code for my submit and preview buttons:
AjaxButton submit = new
AjaxButton(websiteSetting-submit-button)
{
@Override
protected void onError(AjaxRequestTarget target, Form?
form)
{
super.onError(target, form);
feedbackPanel.add(new AttributeModifier(style, true,
new
Model(color:red;)));
target.addComponent(feedbackPanel);
target.addComponent(form);
}
@Override
protected void onSubmit(AjaxRequestTarget target, Form?
form) {
processSubmission(target, form, false);
}
//Prepending the call to set the target to nothing for
normal
form submission.
@Override
protected IAjaxCallDecorator getAjaxCallDecorator() {
return new
AjaxPreprocessingCallDecorator(super.getAjaxCallDecorator()) {
private static final long serialVersionUID = 1L;
@Override
public CharSequence preDecorateScript(CharSequence
script) {
String sJs = document.getElementById(' +
form.getMarkupId() + ').target = '';;
return sJs + script;
}
};
}
};
AjaxSubmitLink preview = new
AjaxSubmitLink(websiteSetting-preview-button) {
@Override
protected void onError(AjaxRequestTarget target, Form?
form)
{
super.onError(target, form);
feedbackPanel.add(new AttributeModifier(style, true,
new
Model(color:red;)));
target.addComponent(feedbackPanel);
target.addComponent(form);
}
@Override
protected void onSubmit(AjaxRequestTarget target, Form?
form) {
setResponsePage(HomePage.class);
}
//Prepending the call to set the target to _blank for
preview submission to new window.
@Override
protected IAjaxCallDecorator getAjaxCallDecorator() {
return new
AjaxPreprocessingCallDecorator(super.getAjaxCallDecorator()) {
private static final long serialVersionUID = 1L;
@Override
public CharSequence preDecorateScript(CharSequence
script) {
String sJs = document.getElementById(' +
form.getMarkupId() + ').target =
'_blank';alert(document.getElementById('
+ form.getMarkupId() + ').target);;
return sJs + script;
}
};
}
};
Thanks,
Jeff
* This e-mail and any files transmitted with it may contain
confidential
and/or privileged information and intended solely for the use of the
individual or entity to whom they are addressed. If you are not the
addressee or authorized to receive this for the addressee, you must not
use,
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
Re: brix and blogs
Haiko, Your work is great because it is right know the only way to decide to use brix. I wonder if there is a way to create users as pages' owners, etc. Because this is the minimal requirement I need to implement it. continue publishing about brix; your article was very clear. I will follow yours. On Tue, Dec 22, 2009 at 7:11 PM, haiko hvdsch...@gmail.com wrote: Fernando, I have written a blog entry on the basic elements of brix. See it here http://www.cybersnippet.nl/blog/entry/brixcms. In the entry is also a link to a live brix demo app. Let me know what you think about it. Greetings, Haiko On Tue, 2009-12-22 at 18:17 -0200, Fernando Wermus wrote: Hi all, I would like to know if there is someone writing about brix in some blog. As the info in brix page is poor, I am looking for another way to undersand better the cms. Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Fernando Wermus. www.linkedin.com/in/fernandowermus
reducing ajax callbacks
I have a page that has 100s of links on them that are all ajax calls. Each one calls the same method but passes in a different id to the method. Apparently there is quite a bit of time building the UI controls (100 ajaxLinks). Is there a way to create a handler that could be reused by all 100 of the links to cut down on overhead? D/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
looking for example wicket and hibernate
Hi I am looking for a real working example on wicket and hibernate. I have read the books 'Wcket in Action', 'Pro Wicket' and other books but none of them give a real working example. Can somebody point me to a real working example or can sent to me. The most problem i have with the configuration in web.xml and using the spring integration. -- regards, John
Re: reducing ajax callbacks
yes, it is trivial to do.
first part of this is building a url. you can see how link does it, but in short
class mylink extends webmarkupcontainer implements ilinklistener {
public void onlinkclicked() {
.. do something
}
}
mylink l=new mylink(..);
string url=urlfor(l, ilinklistener.interface);
this will get you the url that will invoke onlinkclicked method on the
instance l
the second part is performing the actual ajax call. this is trivial
with any third party ajax library out there. if you, however, want
this to work as a regular ajax callback i would take a look at
AjaxLink and also look at wicket-ajax.js to see how wicketAjaxGet
function works.
-igor
On Wed, Dec 23, 2009 at 9:06 PM, Douglas Ferguson
doug...@douglasferguson.us wrote:
I have a page that has 100s of links on them that are all ajax calls.
Each one calls the same method but passes in a different id to the method.
Apparently there is quite a bit of time building the UI controls (100
ajaxLinks).
Is there a way to create a handler that could be reused by all 100 of the
links to cut down on overhead?
D/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: looking for example wicket and hibernate
Do not mix hibernate and wicket (web gui). Keep your persistence logic somewhere else. However, if you want only wicket-spring integration you can find some here: http://www.wicket-library.com/wicket-examples/spring/ ** Martin 2009/12/24 Johan den Boer johanj.denb...@gmail.com: Hi I am looking for a real working example on wicket and hibernate. I have read the books 'Wcket in Action', 'Pro Wicket' and other books but none of them give a real working example. Can somebody point me to a real working example or can sent to me. The most problem i have with the configuration in web.xml and using the spring integration. -- regards, John - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
