Re: Is this right? Seems at odds with wicket philosophy
Why not create a wicket components for the comment div and the
makecomment link. Then in the onClick override of the makecomment link
you can set the visibility of the comment component. This does require a
roundtrip to the server, but is IMO more the wicket-way (tm).
Matthijs
Wayne Pope wrote:
Ok,
so I'm new to this, however things have been progression ok for my first day
with Wicket.
However it seems to me that I must be doing HTML markup manipulation in java
when the manipulation only concerns the view and not the data behind it.
This seems at odds with wicket philosophy. Let me explain:
I have a very simple news feed that I want to be able to comment on, this
textarea should only be visible once I click on a link.
the markup
Make
comment
As there are lots of news items, I need to assign a unique id (markup id,
not wicket id) to the element and the corresponding onclick attribute
in the anchor.
So in the java I have to do it this way:
ListView items = new ListView("newsItems",feed) {
@Override
protected void populateItem(ListItem item) {
FeedItem news = (FeedItem) item.getModelObject();
item.add(new Label("title", new
PropertyModel(news,"title")));
item.add(new Label("description", new
PropertyModel(news,"description")));
final int index = item.getIndex();
item.add(new WebMarkupContainer("makecomment") {
protected void onComponentTag(ComponentTag tag) {
tag.getAttributes().put("onclick","getElementById('comment"+index+"').style.display='';return
false;"); }
});
item.add(new WebMarkupContainer("comment") {
protected void onComponentTag(ComponentTag tag) {
tag.getAttributes().put("id","comment"+index); }
});
}
};
add(items);
Ok so that code is just to demonstrate what I mean. The point is I need to
manipulate the attributes of elements, just so I can setup some javascript
stuff. Is there no better way of just doing this in the markup or some form
of wicket:tag that can insert the current list item index?
thanks
Wayne
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: sneak peek - brix - wicket/jcr cms
Cool. I'll definitely try it out. We're currently using jackrabbit for a wicket project so I'm interested to see what we could gain by using brix. Matthijs Igor Vaynberg wrote: a few of us have been quietly working on a wicket/jcr cms called Brix for a while now. it is almost at a point where we are ready to release a beta, just waiting for wicket-m3 build to go official. in the meanwhile, if you are not afraid of building from source and want a sneak peek, you can check it out here [1]. brix is more of a cms framework/library than a full blown cms. it is designed to be integrated into wicket applications that require cms functionality as part of their feature set. for example, at my company we have built a set of ecommerce tiles (brix tiles are dynamic components that can live inside a cms page) that allow us to build webstores on top of brix. brix includes a url coding strategy (which will hopefully become part of wicket 1.5) that allows for stateless pages as well as url contribution from tiles and query/indexed parameter mixtures. it has been designed with scalability in mind although we have not yet built a caching solution, nor tested if one is necessary. to hopefully preempt some common questions: brix uses a simple plugin system to allow extensibility. we did not use osgi because our time is limited and running wicket inside osgi or osgi inside wicket is not straight forward yet. will we switch to osgi later? maybe. we did not use spring because we did not need the overhead and spring's jcr support is broken because its jcrsessionfactory does not support multiple jcr workspaces so we would have to roll our own anyways. suggestions, feedback, etc are welcome as well as any help. we have not been working on this very long so it is not extremely polished yet. for more info see the website. [1] http://brix-cms.googlecode.com -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Timo Rantalaiho wrote: On Mon, 07 Jul 2008, Matthijs Wensveen wrote: The thing is that when using Ajax you have to specifically add PersonViewer to the AjaxRequestTarget when 'some other component' modifies the Person object. The problem is that 'some other component' might not even know about or have access to PersonViewer (maybe it's a 3rd-party component). OnModelChanged does not work in this case, because there is no call to setModelObject, just to some setter of the Person object. Yep, in our current project we use the WICKET-1312 "broadcaster" approach to solve this. This means that the logic of which component needs to be repainted when something happens is in the UI components. (The domain logic itself we try to put in the domain objects.) So in our model, the other component modifying the Person object would broadcast a PersonModifiedEvent to all PersonModificationReceiver components, who could then act accordingly (typically add themselves to the Ajax request target). There's not a lot of automagical intelligence there, but we have found this way clear and effective. All relationships are "static" on component class level and navigable in the IDE. The proliferation of events and receivers must be watched out for though. I knew about WICKET-1312, but hadn't thought of broadcasting domain object typed events, just things like onClick and such which gives too little information. Thanks for the eyeopener! While Ajax does very nice things to the GUI, it kinda messes up the model-driven (as in wicket model) approach to gui development. That is why I was thinking about some aspect-oriented solution to let components know about model updates, even when they keep a reference to the same object. That's true. It's a pity that for now, Java AOP solutions are still a bit invasive (AFAIK, if you know of some really neat and transparent implementation without -javaagents or special compilers or some such nuisance, I'd be glad to hear :)). We tried sharing models and making them more intelligent and models sending events to registered listeners and whatnot dead chickens before arriving at the current broadcast/receiver approach. When the components are "physically" far away from each other, sharing the model or handling registration and deregistration can get hairy. And to avoid memory leaks, removing the listeners when components are being replaced (e.g. repeater children recreated) should be taken care of carefully in a traditional event-listener mechanism. Maybe listeners could be registered using weak references so that the objects are still garbage collected even when the listener is still alive. However, more experimentation is definitely needed on this, and I'd be very interested on hearing any experiences and ideas! It seems that ajax will be around for some more years, whether we like it or not, so best to make the best out of it :) Best wishes, Timo Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I always find using PropertyChangeSupport and ProperyChangeListener is a
lot of work and kinda pollutes your code. But it is a solution. Maybe a
combination of ProperyChangeListener and AOP could be made to reduce the
required boilerplate code.
Matthijs
Johan Compagner wrote:
thats just a listener interface for example PropertyChangeListener (but you
can make it more specific interface)
Just make a base model that has add/removePropertyChangeListener and let
your components listen to that
johan
On Mon, Jul 7, 2008 at 8:28 AM, Matthijs Wensveen <[EMAIL PROTECTED]>
wrote:
Timo Rantalaiho wrote:
On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends Component {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in
beer)
I have no idea of Johan's project, but normally you just edit an object in
one place at a time, and PersonViewer would be a read-only component with a
model that always pulls the freshest version of the person it is displaying
from the database.
Best wishes,
Timo
The thing is that when using Ajax you have to specifically add PersonViewer
to the AjaxRequestTarget when 'some other component' modifies the Person
object. The problem is that 'some other component' might not even know about
or have access to PersonViewer (maybe it's a 3rd-party component).
OnModelChanged does not work in this case, because there is no call to
setModelObject, just to some setter of the Person object.
While Ajax does very nice things to the GUI, it kinda messes up the
model-driven (as in wicket model) approach to gui development. That is why I
was thinking about some aspect-oriented solution to let components know
about model updates, even when they keep a reference to the same object.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Timo Rantalaiho wrote:
On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends Component {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
I have no idea of Johan's project, but normally you just
edit an object in one place at a time, and PersonViewer
would be a read-only component with a model that always
pulls the freshest version of the person it is displaying
from the database.
Best wishes,
Timo
The thing is that when using Ajax you have to specifically add
PersonViewer to the AjaxRequestTarget when 'some other component'
modifies the Person object. The problem is that 'some other component'
might not even know about or have access to PersonViewer (maybe it's a
3rd-party component). OnModelChanged does not work in this case, because
there is no call to setModelObject, just to some setter of the Person
object.
While Ajax does very nice things to the GUI, it kinda messes up the
model-driven (as in wicket model) approach to gui development. That is
why I was thinking about some aspect-oriented solution to let components
know about model updates, even when they keep a reference to the same
object.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends Component {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
Matthijs
Johan Compagner wrote:
There are many state things in a component. Wicket itself has only a
few like model/visibile/enable. But a developer could add many many
more.
In our project this is easily handled by our components. Every
component knows when it is changed, what ever it is and then a visitor
adds them to ajax. We have a fixed set of components so its not a big
problem.
On 7/4/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
Matej Knopp wrote:
On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
And there is some functionality in there that Wicket might
be better without. For example, onModelChanged / Changing
things become tricky when you share the same model between
different instances. And when using setModelObject() with an
object that is equal to the current model object, but a
different instance (such as a Hibernate-persisted object
bound to the correct session), you have to either do
getModel().setObject() or change the model comparator.
setModelObject isn't the best idea IMHO. Models should support some
kind of state change notifications, we might want to improve that for
1.5, though it probably wouldn't be very easy to do.
Well, we can hardly detect change of propertypromodels unless we pull
and compare the value every time...
Better state change notifications would be a huge improvement IMO
because that way components could add themselves to AjaxRequestTarget
when needed. Currently all Ajax functionality requires Ajaxified
components to know about each other and when they should be displayed.
Some kind of even mechanism as described in
https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
but a model-driven approach would be even better.
I was thinking to support this using annotations and aspects and the
likes, but I haven't had the time to create a proof of concept.
Matthijs
PS. Thread subject has become little different than thread content :)
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Matej Knopp wrote: On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: And there is some functionality in there that Wicket might be better without. For example, onModelChanged / Changing things become tricky when you share the same model between different instances. And when using setModelObject() with an object that is equal to the current model object, but a different instance (such as a Hibernate-persisted object bound to the correct session), you have to either do getModel().setObject() or change the model comparator. setModelObject isn't the best idea IMHO. Models should support some kind of state change notifications, we might want to improve that for 1.5, though it probably wouldn't be very easy to do. Well, we can hardly detect change of propertypromodels unless we pull and compare the value every time... Better state change notifications would be a huge improvement IMO because that way components could add themselves to AjaxRequestTarget when needed. Currently all Ajax functionality requires Ajaxified components to know about each other and when they should be displayed. Some kind of even mechanism as described in https://issues.apache.org/jira/browse/WICKET-1312 would definitely help, but a model-driven approach would be even better. I was thinking to support this using annotations and aspects and the likes, but I haven't had the time to create a proof of concept. Matthijs PS. Thread subject has become little different than thread content :) -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuring wicket:id from Java code in in a page
You might want to use wicket:message in cases like this. See:
http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html
Matthijs
Rakesh Sinha wrote:
Thanks Igor. That works.
Thanks Apache Wicket team once again for a wonderful framework.
On Wed, Jul 2, 2008 at 12:37 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
[title will be here]
just like the span...
-igor
On Tue, Jul 1, 2008 at 9:01 PM, Rakesh Sinha <[EMAIL PROTECTED]> wrote:
I am trying to have the title of a given page, populated from the code.
HTML:
==
wicket:id="mysiteName"
Homepage
message will be here
Java: (HomePage.java only)
=
public class HomePage extends WebPage {
public HomePage(final PageParameters parameters) {
// Add the simplest type of label
add(new Label("message", MESSAGE));
add(new Label("mysiteName", "mysite"));
// TODO Add your page's components here
}
static final String MESSAGE = "If you see this message wicket is
properly configured and running";
}
I am getting the following error.
ERROR - RequestCycle - The component(s) below failed to
render. A common problem is that you have added a component in code
but forgot to reference it in the markup (thus the component will
never be rendered).
1. [Component id = mysiteName, page = pages.HomePage, path =
0:mysiteName.Label, isVisible = true, isVersioned = true]
org.apache.wicket.WicketRuntimeException: The component(s) below
failed to render. A common problem is that you have added a component
in code but forgot to reference it in the markup (thus the component
will never be rendered).
1. [Component id = mysiteName, page = pages.HomePage, path =
0:mysiteName.Label, isVisible = true, isVersioned = true]
at org.apache.wicket.Page.checkRendering(Page.java:1115)
Can somebody help me here.
I am using this with Wicket 1.3.4 . (with Jetty engine).
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Firefox 3 Back button and BaseTree
Is there a bugzilla id we could track (spam :) )? Matej Knopp wrote: Firefox caches the wrong version of DOM with the page. Unfortunately the only workaround I know about is to force firefox reloading page on backbutton by sending the no-store header. Look at WebPage#setHeaders. -Matej On Fri, Jun 27, 2008 at 11:06 PM, Kaspar Fischer <[EMAIL PROTECTED]> wrote: I derive BaseTree and have run into a problem with Firefox 3 (FF 2 and IE 7 work fine). If I expand an node of the tree, click any link on the page, and hit the Back button, FF 3 returns to the previous page but has -- in contrast to all other mentioned browsers -- the tree closed. Clicking on the tree shows the following message There was a problem updating the tree. It might be caused be the old page being cached by the browser. It is recommended to reload the page. Do you want to reload it? Is there any workaround for this? Many thanks, Kaspar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
Yes, of course. But the form is not posted when the client side does not validate. Of course the posted form is validated on the server too. Anyway, the nice thing is that you only have to say something like setClientSideValidation(true) and it just works. It's all very transparent, which is cool. I'm not a M$ fanboy or anything (if I was, I wouldn't even be typing this), but I did like that particular feature. Johan Compagner wrote: Fallback? That should always be done fallback or not, clientside is jus a quicker feedback to the user, the real validation should always be done after that on the serverside On 6/26/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: I know ASP.Net has this too, and falls back to the server when client side validation is not possible (or is hacked by a smarter than average user). Something could be done. I think would be worth the time when you have it (time, that is). I'd start with a separate project, so that people can try it out. Matthijs Manuel Corrales wrote: Hi, i dont want to be flamed by this post, i have read on some places some not very polite things about wicket vs taperstry. I think that all frameworks have pro and cons. Here is the thing, i was using Tapestry 5 for a while, and now i am developing with wicket. One thing i liked about T5 was the "magic" on the client side validation without the need to write javascript, and it worked pretty good. I really do not have the time now, but it would be great to accomplish something like this: RequiredTextField tf = new tf.enableClientSideValidation(); my approach would be to borrow the T5 code to generate the required javascript. Is this idea worth the time? Best regards. Manuel. -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redirect page in the constructor
System.exit(0); Igor Vaynberg wrote: if you can find another way to abort creation of a class instance in java feel free to let us know. -igor On Thu, Jun 26, 2008 at 4:29 AM, Eyal Golan <[EMAIL PROTECTED]> wrote: Igor, That is what we used before. Then I looked on the links above, tried the setResponsePage and found out that it works. After your answer, I understand that it does pollute the page map. I'll change to use the Exception instead. IMHO it's not a "nice" way to implement such a feature. On Wed, Jun 25, 2008 at 5:11 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: use restartresponseexception instead -igor On Wed, Jun 25, 2008 at 5:36 AM, Eyal Golan <[EMAIL PROTECTED]> wrote: Hi, After reviewing some discussion regarding the issue. http://issues.apache.org/jira/browse/WICKET-696 and http://www.mail-archive.com/[EMAIL PROTECTED]/msg30288.html What is the conclusion? Is the original page being mapped or no? thanks -- Eyal Golan [EMAIL PROTECTED] Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eyal Golan [EMAIL PROTECTED] Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation
I know ASP.Net has this too, and falls back to the server when client side validation is not possible (or is hacked by a smarter than average user). Something could be done. I think would be worth the time when you have it (time, that is). I'd start with a separate project, so that people can try it out. Matthijs Manuel Corrales wrote: Hi, i dont want to be flamed by this post, i have read on some places some not very polite things about wicket vs taperstry. I think that all frameworks have pro and cons. Here is the thing, i was using Tapestry 5 for a while, and now i am developing with wicket. One thing i liked about T5 was the "magic" on the client side validation without the need to write javascript, and it worked pretty good. I really do not have the time now, but it would be great to accomplish something like this: RequiredTextField tf = new tf.enableClientSideValidation(); my approach would be to borrow the T5 code to generate the required javascript. Is this idea worth the time? Best regards. Manuel. -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting HiddenField name attrribute value
Something like:
ThisComponent.html:
void();
ThisComponent.java:
//..
final PackagedTextTemplate template = new
PackagedTextTemplate(ThisComponent.class, "ThisComponent.js.template");
Label script = new Label("script", new Model() {
private static final long serialVersionUID = 1L;
@Override
public Object getObject() {
Map variables = new HashMapString>();
variables.put("markupId", ThisComponent.this.getMarkupId());
return template.interpolate(variables).asString();
}
});
script.setEscapeModelStrings(false);
add(script);
ThisComponent.js.template:
|document.getElementById("${markupId}").onmouseover = function() {|| alert("Hello
world!"); ||};
|
Cheers,
Matthijs
Ritz123 wrote:
Matthijs,
Those are good suggestions. I would have gone server side myself. There is a
trade off user experience vs. more robust and it just so happened this time
we are going with better user experience hence the use of javascript. The
javascript, I want to use is very basic, thats the reason why I am not doing
AJAX as there is no need to even go to server side partially. Javascript
will be used purely on the client just to update inner html. Just to give
you an idea - this is for the e-commerce checkout where the entire checkout
can be done from 1 page only with very few clicks, it wont be possible
without the use of javascript.
I didnt find any documentation on using templates for javascript - will
appreciate any pointers.
Thanks
Matthijs Wensveen-2 wrote:
Is there any specific reason you don't want to do this server side? Not
using javascript would make the application more accessible, and
probable also more robust and secure. Unless you're targeting some very
specific user group, I always try not to depend on javascrip / ajax
(that's why I love the AjaxFallback stuff in wicket so much).
Just my 2c.
Matthijs
PS. If you must use javascript, why not use the hidden field's id, which
can be controlled with setMarkupId. But it might be better not to use
setMarkupId (to avoid id collisions). You could write some javascript
(with use of templates) that fills in the markupId (getMarkupId)
dynamically.
Ritz123 wrote:
Hi,
Is it possible to set specific name to the hidden field component?
Here is my usage scenario -
1. I have radio group for shipping options on a page.
2. Depending on the shipping option selected, I need to show the order
total
changed
2. radio has associated model which obviously contains more information
than
just the shipping price
The only way I can think of doing this efficiently without going to the
server side is by using hidden fields for shipping costs. Using the
javascript to update the total on the page. Problem is, seems like hidden
field names cannot be specified or controlled and hence cannot be
referenced
by javascript precisely.
Correct me if I am wrong, also let me know if there is a better way of
doing
this.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting HiddenField name attrribute value
Is there any specific reason you don't want to do this server side? Not using javascript would make the application more accessible, and probable also more robust and secure. Unless you're targeting some very specific user group, I always try not to depend on javascrip / ajax (that's why I love the AjaxFallback stuff in wicket so much). Just my 2c. Matthijs PS. If you must use javascript, why not use the hidden field's id, which can be controlled with setMarkupId. But it might be better not to use setMarkupId (to avoid id collisions). You could write some javascript (with use of templates) that fills in the markupId (getMarkupId) dynamically. Ritz123 wrote: Hi, Is it possible to set specific name to the hidden field component? Here is my usage scenario - 1. I have radio group for shipping options on a page. 2. Depending on the shipping option selected, I need to show the order total changed 2. radio has associated model which obviously contains more information than just the shipping price The only way I can think of doing this efficiently without going to the server side is by using hidden fields for shipping costs. Using the javascript to update the total on the page. Problem is, seems like hidden field names cannot be specified or controlled and hence cannot be referenced by javascript precisely. Correct me if I am wrong, also let me know if there is a better way of doing this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modal Window question
The javascript to close the ModalWindow is returned by a private method
of ModalWindow:
/**
* @return javascript that closes current modal window
*/
private static String getCloseJavacript()
{
return "var win;\n" //
+ "try {\n" + "win = window.parent.Wicket.Window;\n"
+ "} catch (ignore) {\n"
+ "}\n"
+ "if (typeof(win) == \"undefined\" || typeof(win.current)
== \"undefined\") {\n"
+ " try {\n"
+ " win = window.Wicket.Window;\n"
+ " } catch (ignore) {\n"
+ " }\n"
+ "}\n"
+ "if (typeof(win) != \"undefined\" && typeof(win.current)
!= \"undefined\") {\n"
+ "window.parent.setTimeout(function() {\n" + "
win.current.close();\n"
+ "}, 0);\n"
+ "}";
}
There ya go.
mfs wrote:
Isn't there a way to call the appropriate javascript which does the
modal-close..
mfs wrote:
Guys,
I am posting this question yet again, hoping to get some feedback...
The problem is regarding modal windows, as to how close it, when a form
(within it) is submitted in a new window. Any suggestions
Thanks in advance
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modal Window question
Awkward.. that's the first letter in AJAX! :D
mfs wrote:
That is certainly an option, but i dont like the idea of the timer, since
there could be scenarios where the user does the form submission (resulting
in a new window), and lets say i set the timer to 2 seconds, now in case the
user decides to close the new browser window rightaway, and comes back and
while he is trying to click some other button on the modal window (which has
other forms too), the modal window all of sudden vanishes and that would
just be a bit awkward, thats just one example, even if the timer is set to a
shorter time the response itself might take a while (due to load/traffic or
other reasons) and user might see this sudden invisibility of the modal when
he was trying to do somethingthats why i would rather close the modal
window as soon as the new browser window loads up or even before..
Matthijs Wensveen-2 wrote:
Hmm, that's a hard one, because you have a requestTarget that does not
even look at the modal window (I think). A solution (albeit a bit hacky)
is to set some parameter in the session. Then, add an
AbstractAjaxTimerBehaviour to the modal window that checks for the
session parameter in onTimer and when it is set calls
ModalWindow.this.close(target). Of course the ugliness lies in the
session state tweaking, so if there's a cleaner solution for that, that
would be preferable.
Matthijs
mfs wrote:
No i mean a separate browser window, where i display the results of the
form-submission.
Matthijs Wensveen-2 wrote:
What do you mean by "submitted in a new window"? The modal window
itself?
Matthijs
mfs wrote:
Guys,
I am posting this question yet again, hoping to get some feedback...
The problem is regarding modal windows, as to how close it, when a form
(within it) is submitted in a new window. Any suggestions
Thanks in advance
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modal Window question
Hmm, that's a hard one, because you have a requestTarget that does not even look at the modal window (I think). A solution (albeit a bit hacky) is to set some parameter in the session. Then, add an AbstractAjaxTimerBehaviour to the modal window that checks for the session parameter in onTimer and when it is set calls ModalWindow.this.close(target). Of course the ugliness lies in the session state tweaking, so if there's a cleaner solution for that, that would be preferable. Matthijs mfs wrote: No i mean a separate browser window, where i display the results of the form-submission. Matthijs Wensveen-2 wrote: What do you mean by "submitted in a new window"? The modal window itself? Matthijs mfs wrote: Guys, I am posting this question yet again, hoping to get some feedback... The problem is regarding modal windows, as to how close it, when a form (within it) is submitted in a new window. Any suggestions Thanks in advance -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generic component placeholder
With Panel you know you always have the right markup so that is good.
The disadvantage is that you'd then have to write panels for everything
the ComponentFactory should be able to produce.
Maybe you could always return a container that overrides onComponentTag
and set the tag's name according to the contained component. I don't
know if this will even work, but you still have the disadvantage that
you have to know the tagname for everything that could be produced /
contained and do a lot of instanceof's. For some components this is even
impossible, for example Link, which works on any html tag (for other
tags than it writes an onclick handler).
You can also do things with IMarkupResourceStreamProvider. That way the
markup could dynamically be produced to be according to what you need.
Anyway, it quickly becomes complex. Igor's suggestion has the advantage
that it's very clean and comprehensible. So if the ComponentFactory
produces only a few components, write panels for them and your problem
is solved.
Matthijs
Igor Vaynberg wrote:
wicket's default components do not mutate markup, so you cannot do
that. a better contract is eg
componentfactor { panel getpanel(string id); } eg ITab in extensions.
that way you know it will always work.
-igor
On Wed, Jun 18, 2008 at 7:39 PM, Dreamage <[EMAIL PROTECTED]> wrote:
Hi,
If for example I have the following panel:
< span wicket:id="genericComponent"/>
And I want to insert a component at the place of span tag, but the component
is not instanciated by the panel ... it's provided by a factory. Here is the
code :
public class MyPanel extends Panel{
public MyPanel(String id, ComponentFactory factory) {
super(id);
//Create a new generic component using a specific id
add(factory.getComponent("genericComponent"));
}
}
The problem is that if the factory returns a TextField, the placeholder tag
need to be a input tag instead of a span. Is there a generic wicket tag that
could allow me to indicate where a component goes without binding it to a
specific tag ? If not, can this be done another way ?
Thanks
--
View this message in context:
http://www.nabble.com/Generic-component-placeholder-tp17996229p17996229.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modal Window question
What do you mean by "submitted in a new window"? The modal window itself? Matthijs mfs wrote: Guys, I am posting this question yet again, hoping to get some feedback... The problem is regarding modal windows, as to how close it, when a form (within it) is submitted in a new window. Any suggestions Thanks in advance -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: isVisible vs. setVisible
Nice!
Johan Compagner wrote:
Igor already has plans to fix/change that
something like isVisible and setVisible both final
and then you can override visible() that we check for you in the isVisible()
method (but first also we check our own flag)
so both setVisible() and your overridden visible() are working fine. (and we
can test other stuff like isVisibleInHierarchy and so on.
johan
On Mon, Jun 16, 2008 at 11:52 PM, Matthijs Wensveen <[EMAIL PROTECTED]>
wrote:
Of course I have a few things to learn, and I hope I never stop learning.
The article you provide is interesting.
My opinion is that for domain entity objects, getters and setters are
certainly not evil. For classes that are more service-like, getters and
setters could be useful but should be considered well. In case you choose
not to have a getter and a setter one should be extra careful when choosing
method names. I usually expect a setVisible method when there is also an
isVisible method. Immutable classes, or classes with read-only properties
can choose to only provide a getter for some properties. But if a method
like isVisible is intended to be overridden something like public boolean
visible() might be better. But I guess this is also a matter of style and
taste.
As for Component.set/isVisible, I like that I can do both, even if it gives
me the possibility of ambiguous code like new Component() {isVisible()
{return true;};}.setVisible(false) or something like that (it is actually
not ambiguous at all of course, but you do have to read extra careful). So
whatever reason you (core devs) originally had for providing a setter, I am
thankful for that.
Matthijs
Jonathan Locke wrote:
i think you may have a few things to learn and it is not exactly
controversial to prefer immutability or encapsulation... setters break
encapsulation and i think it is safe to say decades of experience with
object systems is on my side, including industry luminaries like:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Matthijs Wensveen-2 wrote:
Jonathan Locke wrote:
true.
in the isVisible impl you could lazy-init cache a transient Boolean
until
end request where you set it null.
setters are evil.
..but it's good to have choice. *And* setVisible is not a normal setter,
because it returns the component, which makes it easy to add an initially
invisible component like: add(new Label("profanity",
"[EMAIL PROTECTED]").setVisible(false));
Also, with is/setVisible you van use the component with a propertymodel
to have some other component toggle the visibility of another component.
This way you have the best of both worlds.
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Matthijs
egolan74 wrote:
Yes but ...
isVisible may be triggered several times, while setVisible should only
be
called once (say if I do it only once after creating the component).
Usually I prefer the state driven way, but what if the logic has a lot
of
overhead?
Jonathan Locke wrote:
isVisible is generally better imo because it is state driven. if you
push instead of pull, the state can get stale.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: isVisible vs. setVisible
Never underestimate the power of the Dark Side! :)
Jonathan Locke wrote:
i imagine setVisible came from me. just because setters are evil and you
should avoid them when you can does not mean you should not use them when
you need them.
Matthijs Wensveen-2 wrote:
Of course I have a few things to learn, and I hope I never stop
learning. The article you provide is interesting.
My opinion is that for domain entity objects, getters and setters are
certainly not evil. For classes that are more service-like, getters and
setters could be useful but should be considered well. In case you
choose not to have a getter and a setter one should be extra careful
when choosing method names. I usually expect a setVisible method when
there is also an isVisible method. Immutable classes, or classes with
read-only properties can choose to only provide a getter for some
properties. But if a method like isVisible is intended to be overridden
something like public boolean visible() might be better. But I guess
this is also a matter of style and taste.
As for Component.set/isVisible, I like that I can do both, even if it
gives me the possibility of ambiguous code like new Component()
{isVisible() {return true;};}.setVisible(false) or something like that
(it is actually not ambiguous at all of course, but you do have to read
extra careful). So whatever reason you (core devs) originally had for
providing a setter, I am thankful for that.
Matthijs
Jonathan Locke wrote:
i think you may have a few things to learn and it is not exactly
controversial to prefer immutability or encapsulation... setters break
encapsulation and i think it is safe to say decades of experience with
object systems is on my side, including industry luminaries like:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Matthijs Wensveen-2 wrote:
Jonathan Locke wrote:
true.
in the isVisible impl you could lazy-init cache a transient Boolean
until
end request where you set it null.
setters are evil.
..but it's good to have choice. *And* setVisible is not a normal setter,
because it returns the component, which makes it easy to add an
initially invisible component like: add(new Label("profanity",
"[EMAIL PROTECTED]").setVisible(false));
Also, with is/setVisible you van use the component with a propertymodel
to have some other component toggle the visibility of another component.
This way you have the best of both worlds.
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Matthijs
egolan74 wrote:
Yes but ...
isVisible may be triggered several times, while setVisible should only
be
called once (say if I do it only once after creating the component).
Usually I prefer the state driven way, but what if the logic has a lot
of
overhead?
Jonathan Locke wrote:
isVisible is generally better imo because it is state driven. if you
push instead of pull, the state can get stale.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: isVisible vs. setVisible
Of course I have a few things to learn, and I hope I never stop
learning. The article you provide is interesting.
My opinion is that for domain entity objects, getters and setters are
certainly not evil. For classes that are more service-like, getters and
setters could be useful but should be considered well. In case you
choose not to have a getter and a setter one should be extra careful
when choosing method names. I usually expect a setVisible method when
there is also an isVisible method. Immutable classes, or classes with
read-only properties can choose to only provide a getter for some
properties. But if a method like isVisible is intended to be overridden
something like public boolean visible() might be better. But I guess
this is also a matter of style and taste.
As for Component.set/isVisible, I like that I can do both, even if it
gives me the possibility of ambiguous code like new Component()
{isVisible() {return true;};}.setVisible(false) or something like that
(it is actually not ambiguous at all of course, but you do have to read
extra careful). So whatever reason you (core devs) originally had for
providing a setter, I am thankful for that.
Matthijs
Jonathan Locke wrote:
i think you may have a few things to learn and it is not exactly
controversial to prefer immutability or encapsulation... setters break
encapsulation and i think it is safe to say decades of experience with
object systems is on my side, including industry luminaries like:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Matthijs Wensveen-2 wrote:
Jonathan Locke wrote:
true.
in the isVisible impl you could lazy-init cache a transient Boolean until
end request where you set it null.
setters are evil.
..but it's good to have choice. *And* setVisible is not a normal setter,
because it returns the component, which makes it easy to add an
initially invisible component like: add(new Label("profanity",
"[EMAIL PROTECTED]").setVisible(false));
Also, with is/setVisible you van use the component with a propertymodel
to have some other component toggle the visibility of another component.
This way you have the best of both worlds.
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Matthijs
egolan74 wrote:
Yes but ...
isVisible may be triggered several times, while setVisible should only
be
called once (say if I do it only once after creating the component).
Usually I prefer the state driven way, but what if the logic has a lot
of
overhead?
Jonathan Locke wrote:
isVisible is generally better imo because it is state driven. if you
push instead of pull, the state can get stale.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: isVisible vs. setVisible
Martijn Dashorst wrote:
On Mon, Jun 16, 2008 at 3:48 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Why? Are we not allowed an opinion?
Why off-course! Am I not allowed to be scared? ;P
And from an OO point of view, I
can see how setters break encapsulation: they expose the internal
state of an object. In the case of setVisible this is exacerbated
because the semantics of the following are vague:
Label l = new Label("l", "foo") {
@Override boolean isVisible() { return false; }
};
l.setVisible(true);
add(l);
So either you'd want final to be the default, or you'd consider
setters evil. :-D
Hehe. Maybe in that case you should override setVisible as well to throw
an UnsupportedOperationException?
I disagree that you expose internal state. It's hardly internal when
there is a public setter. But I agree that it is often very useful to
override the getter (isser for booleans?) when there is a hard
dependency between the component visibility and some other state. As I
said: it's good to have choice.
Martijn
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: isVisible vs. setVisible
Jonathan Locke wrote:
true.
in the isVisible impl you could lazy-init cache a transient Boolean until
end request where you set it null.
setters are evil.
..but it's good to have choice. *And* setVisible is not a normal setter,
because it returns the component, which makes it easy to add an
initially invisible component like: add(new Label("profanity",
"[EMAIL PROTECTED]").setVisible(false));
Also, with is/setVisible you van use the component with a propertymodel
to have some other component toggle the visibility of another component.
This way you have the best of both worlds.
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Matthijs
egolan74 wrote:
Yes but ...
isVisible may be triggered several times, while setVisible should only be
called once (say if I do it only once after creating the component).
Usually I prefer the state driven way, but what if the logic has a lot of
overhead?
Jonathan Locke wrote:
isVisible is generally better imo because it is state driven. if you
push instead of pull, the state can get stale.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chaining components
That's what I said ;) Johan Compagner wrote: i think they are pointing to this one: https://issues.apache.org/jira/browse/WICKET-1312 On Mon, Jun 16, 2008 at 9:21 AM, Jonathan Locke <[EMAIL PROTECTED]> wrote: what bug # is that one? igor.vaynberg wrote: On Sun, Jun 15, 2008 at 11:38 AM, Martin Makundi <[EMAIL PROTECTED]> wrote: Hi! When I chain components, comboboxes and tables etc., I find myself repeatedly solving the same problem: * the parent component causes a data reload if you chain your models properly (make child's model depend on parent's model) this should work transparently. * the parent component causes an ajax refresh if the parent component repaints itself then all child components are repainted as well... Has someone found a generic eventlistener-like solution to this? there is a patch in jira for a generic event/listener mechanism, but it wont happen until 1.5 because it requires api breaks. -igor My current inline implementations have become quite messy to follow and I must make some major refactoring soon, as I am beginning to understand how the Wicket framework operates - and it would not hurt to plug in some neat ready solution you have come up with that keeps the code clean and structured. I am thinking something along the lines of a hashmap, I would just push the reloaders and refreshers there out of sight ... ** Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Chaining-components-tp17853298p17859174.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chaining components
Martin Makundi wrote: I've been thinking about writing aspects that fire Component.onModelChanged even when the model's object changed (possibly deep within an object hierarchy). Do you have a demo about this? Unfortunately no, I didn't have the time to convert my brain contents to java code... I am about to write a HierarchicalAjaxRefreshTargetPropagator soon just to get a feeling if it is a bad idea... I will let subscribers know. If you just need a reference to the AjaxRequestTarget then you can do RequestCycle.get().getRequestTarget() and do an instanceof with AjaxRequestTarget. Matthijs ** Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chaining components
Martin Makundi wrote:
Now if I change the country, I must change the list of allowed values
for cityCombo.
http://wicketstuff.org/wicket13/ajax/choice
Thanks, I remember seeing that but already forgot about the idea that
a dropdown choice can be a model, and a smart model too.
interface statechangedlistener { protected void
onstatechanged(ajaxrequesttarget t); }
city.onupdate() { getpage().visitchildren(statechangedlistener.class) {...}}
there is your basic listener support.
Ok. Something like this. I do not know if I want to bind it directly
to the page hierarcy though, it might be some other construct just for
that purpose. And I do not know if I want a listener interface if I
can make the models reload themselves -> in that case the construct
should maybe automatically attach onchangelisteners? Maybe, e.g.,
mutable/immutable treenodes...
I've been thinking about writing aspects that fire
Component.onModelChanged even when the model's object changed (possibly
deep within an object hierarchy). Another option would be to use
PropertyChangeSupport. Either way, you'd never require listeners or
other complex notification structures. This would be especially useful
with AJAX, because then all components that get onModelChanged can add
themselves to the AjaxRequestTarget.
By the way, the jira patch Igor mentioned:
https://issues.apache.org/jira/browse/WICKET-1312. I really like it.
Matthijs.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
Eelco Hillenius wrote: It's good to know that when you reach the same conclusion it is a deliberate one. BTW, interfaces are useful for this, but not a necessity. Or am I the only one thinking that No, I agree with you mostly. However, I was trying (back then) to define separate dimensions of components (the fact that they can be rendered is one, and for form components for instance, the fact that they can validate is another). If you have a bunch of useful distinctions like that, you can just decorate them for specific purposes. Maybe. Yeah. Some problem domains are better suited for this kind of interfacing than others. In one project we work on we have interfaces like PropertyHolder and TemplateHolder, but other projects keep to a stricter OO hierarchy with only one or two interfaces at the base (or top?) I can see merit in interfaces like IRenderable and IValidatable. An interface for lifecycle could be useful too. One problem could be that when only Component (or somesuch) implements all the useful interfaces, people are never going to implement one of the interfaces themselves. An interesting framework could be Qi4J, to be able to independently implement the interfaces. They gave a presentation at the wicket meetup in amsterdam (I wasn't there, but heard about it and looked it up). (I seem to be... hmm...). More interfaces mean even more scrolling through the I's in the javadoc, no, lol. Indeed, it gets ugly pretty fast. Mixins and interfaces with implementations like scala has would be wonderful here, but alas, we'll have to work with Java. Java is not so bad. We'll just have to wait until someone writes a java2scala conversion app :) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
Ah, you beat me to that. I should've read the thread entirely before posting :) Martijn Dashorst wrote: Or with qi4j (http://qi4j.org) Martijn On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: It's good to know that when you reach the same conclusion it is a deliberate one. BTW, interfaces are useful for this, but not a necessity. Or am I the only one thinking that No, I agree with you mostly. However, I was trying (back then) to define separate dimensions of components (the fact that they can be rendered is one, and for form components for instance, the fact that they can validate is another). If you have a bunch of useful distinctions like that, you can just decorate them for specific purposes. Maybe. (I seem to be... hmm...). More interfaces mean even more scrolling through the I's in the javadoc, no, lol. Indeed, it gets ugly pretty fast. Mixins and interfaces with implementations like scala has would be wonderful here, but alas, we'll have to work with Java. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
Eelco Hillenius wrote: True, it's been weighing the disadvantages vs the advantages, and so far, ensuring that we wouldn't paint ourselves in the corner too quickly won over flexibility. To make this 'painless' though, we'd probably need a whole bunch of interfaces. We've looked into moving to a more interface based approach in the past for Wicket, but we concluded that it just got too crazy, increasing the complexity of the API considerably, and had all the disadvantages of interfaces over abstract classes (no guaranteed behavior, everything has to be public and abstract). We might just come to that same conclusion again. It's good to know that when you reach the same conclusion it is a deliberate one. BTW, interfaces are useful for this, but not a necessity. Or am I the only one thinking that (I seem to be... hmm...). More interfaces mean even more scrolling through the I's in the javadoc, no, lol. Matthijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Component easier to Generify
Igor Vaynberg wrote: On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: By the way, the article I supplied and the article on wikipedia do just the same thing. If you look at VerticalScrollBarDecorator.draw you'll see that it delegates the method to the wrapped Window. decorator classes in the onjava article do not perform method delegation across all methods in JComponent, therefore its not a decorator by your own definition? It's still is a decorator, but I agree it does not do exactly as I thought a proper decorator should do. The delegation is still there, but it is hidden because the wrapped class is added as a child to the decorator. The super.xxx calls take care of calling the needed methods on the wrapped class. But this only works for hierarchies like swing. Hmm.. if I were very puristic, I might not call this decoration at all, in the OO-sense of the pattern. This really just takes a component and puts it somewhere else. It *is* transparent to the (api) user however. It doesn't need to know or care this has happened, so in that sense it is a decorator. Also, I did say: "It is not entirely impossible to decorate a class with final methods, you just can't delegate the final methods" . So, "my definition" does not enforce that every method should be delegated. You may read the words "Implementing each and every method of a class and delegating to another class is indeed what is needed" as "Implementing each and every method of a class and delegating to another class is indeed what is *usually / generally* needed" :) Also look at the C++ example. C++ doesn't have interfaces. So, maybe this is a ui decorator as well...? actually c++ does have interfaces, they are modeled as "pure virtual" classes, which is what the c++ Window class in the wikipedia article is. Okay, but then abstract classes in java are interfaces as well :). You said decoration *only* works with interfaces, and there was no way for me to know that your notion of the term interface included classes as well (because then what are we even arguing about :) ) Hm, anyway, let's drop the almost religious fanaticism. We could argue about the definition of the term decorator all year, presumably, but whatever it is called, what I want can't be done in wicket because of some final methods that are in the way. The Link.onClick problem is still unsolved. Matthijs -igor At the end of the article there is a list of other design patterns from the GoF book, unfortunately I couldn't find anything about the software decorator pattern you mentioned (also googled it without avail). So, okay, let's end this discussion for Godwin's sake. I really do want to know how to add behaviour in a transparent way to an existing Link's onClick method. Using Behavior or some other means. AOP is an option but feels hacky just to do this (pointcuts should generally match more than one joinpoint). Event listeners are another (but I won't dare begin that discussion again). Best regards, Matthijs Igor Vaynberg wrote: looked over the article. what they do is a ui decorator, it is not the software decorator pattern. there is no method delegation to the child component. what they create is a composite, you can do the same thing in wicket with a Border. -igor On Thu, Jun 12, 2008 at 9:55 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: right. so when you would do it with a class you will actually have to rewire all the methods to forward to the delegate instead of calling super. that is pure insanity and does not make any sense when methods hold logic. that is why it works with an interface, no logic for you to override and forward to the delegate, only the message dispatch itself. sure, technically you can do it even with a concrete class, but you can also do a lot of other things that dont make sense. -igor On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Igor Vaynberg wrote: look at the java example. notice Window is an interface. Yeah, but that's just because it's good practice to use the interface when there is one. Notice that the actually decorated class is a new SimpleWindow() in DecoratedWindowTest. Window might as well have been an abstract class, or even a concrete one. The idea is that the contract of the class you wrap is maintained, if that is an interface your decorator implements that, when it's a class your decorator extends it. Same idea. Of course, interfaces are cleaner and you can even decorate more then one interface when you want to, but decorating a class is not uncommon practice (at least where I come from). Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html eg you cant do: add(new Decorat
Re: Making Component easier to Generify
I am not aware of a distinction between software decorator and ui decorator. But seeing as wicket is a ui framework, I'll go with ui decorator. Border looks somewhat like a decorator, but since it does not wrap another component, it is not. Also Border needs different markup than the component it 'decorates' which makes it nontransparent, which is kind of the point of decorators. I like to thing of decorators as classes that piggyback behavior on existing instances. Implementing each and every method of a class and delegating to another class is indeed what is needed, but is certainly not insanity. If you use eclipse you can do this easily by adding a member field of a certain type, right-click it and select Source > Generate Delegate Methods. When decorating a class is common and intended use of that class, an API usually supplies a SomethingSomethingDecorator class (extends / implements SomethingSomething) that delegates every method by default. You'd then only have to subclass that class. Calling super in methods that only implement an interface as in your reply is just not possible (does not even compile), you need to subclass in order to be able to do that. To return to the final method argument. It is not entirely impossible to decorate a class with final methods, you just can't delegate the final methods. An important one to be able to delegate in wicket is MarkupContainer.add. Otherwise you'd break the hierarchy with a decorated MarkupContainer. By the way, the article I supplied and the article on wikipedia do just the same thing. If you look at VerticalScrollBarDecorator.draw you'll see that it delegates the method to the wrapped Window. Also look at the C++ example. C++ doesn't have interfaces. So, maybe this is a ui decorator as well...? At the end of the article there is a list of other design patterns from the GoF book, unfortunately I couldn't find anything about the software decorator pattern you mentioned (also googled it without avail). So, okay, let's end this discussion for Godwin's sake. I really do want to know how to add behaviour in a transparent way to an existing Link's onClick method. Using Behavior or some other means. AOP is an option but feels hacky just to do this (pointcuts should generally match more than one joinpoint). Event listeners are another (but I won't dare begin that discussion again). Best regards, Matthijs Igor Vaynberg wrote: looked over the article. what they do is a ui decorator, it is not the software decorator pattern. there is no method delegation to the child component. what they create is a composite, you can do the same thing in wicket with a Border. -igor On Thu, Jun 12, 2008 at 9:55 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: right. so when you would do it with a class you will actually have to rewire all the methods to forward to the delegate instead of calling super. that is pure insanity and does not make any sense when methods hold logic. that is why it works with an interface, no logic for you to override and forward to the delegate, only the message dispatch itself. sure, technically you can do it even with a concrete class, but you can also do a lot of other things that dont make sense. -igor On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Igor Vaynberg wrote: look at the java example. notice Window is an interface. Yeah, but that's just because it's good practice to use the interface when there is one. Notice that the actually decorated class is a new SimpleWindow() in DecoratedWindowTest. Window might as well have been an abstract class, or even a concrete one. The idea is that the contract of the class you wrap is maintained, if that is an interface your decorator implements that, when it's a class your decorator extends it. Same idea. Of course, interfaces are cleaner and you can even decorate more then one interface when you want to, but decorating a class is not uncommon practice (at least where I come from). Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html eg you cant do: add(new DecoratedComponent(someOtherComponent)); No, because component has final methods that you can't override so you can't delegate to them (that whas my point), but not because you can't decorate a class. Matthijs. PS. If you insist on that you can only decorate an interface, I'll call it wrap-extend or something :) -igor On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Why would the decorator design pattern only work with interfaces? Maybe we're talking about two different this here? (I'm talking about this one: http://en.wikipedia.org/wiki/Decorator_pattern) I can see why behaviors were introduced. A simple example: a factory m
Re: Making Component easier to Generify
Igor Vaynberg wrote: look at the java example. notice Window is an interface. Yeah, but that's just because it's good practice to use the interface when there is one. Notice that the actually decorated class is a new SimpleWindow() in DecoratedWindowTest. Window might as well have been an abstract class, or even a concrete one. The idea is that the contract of the class you wrap is maintained, if that is an interface your decorator implements that, when it's a class your decorator extends it. Same idea. Of course, interfaces are cleaner and you can even decorate more then one interface when you want to, but decorating a class is not uncommon practice (at least where I come from). Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html eg you cant do: add(new DecoratedComponent(someOtherComponent)); No, because component has final methods that you can't override so you can't delegate to them (that whas my point), but not because you can't decorate a class. Matthijs. PS. If you insist on that you can only decorate an interface, I'll call it wrap-extend or something :) -igor On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Why would the decorator design pattern only work with interfaces? Maybe we're talking about two different this here? (I'm talking about this one: http://en.wikipedia.org/wiki/Decorator_pattern) I can see why behaviors were introduced. A simple example: a factory method creates a link. In my subclass I want the same link with the same onClick behavior but I also want "hello" to be outputted to System.out. How would I go about doing this with a Behavior? I couldn't figure it out... (which isn't saying it's impossible). Matthijs [EMAIL PROTECTED] wrote: decorators only work with interfaces, component class is not. This is part of the reason why we have behaviors -igor On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Some useful design patterns like Decorator don't work with final methods. Wicket components sometimes have overridable factory methods for child components. The decorator pattern could be very useful here, because you'd be able to decorate the original component with some extra functionality (Link.onClick for example). Unfortunately this doesn't work because some methods are final. Matthijs Igor Vaynberg wrote: i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable
Re: Making Component easier to Generify
Why would the decorator design pattern only work with interfaces? Maybe we're talking about two different this here? (I'm talking about this one: http://en.wikipedia.org/wiki/Decorator_pattern) I can see why behaviors were introduced. A simple example: a factory method creates a link. In my subclass I want the same link with the same onClick behavior but I also want "hello" to be outputted to System.out. How would I go about doing this with a Behavior? I couldn't figure it out... (which isn't saying it's impossible). Matthijs [EMAIL PROTECTED] wrote: decorators only work with interfaces, component class is not. This is part of the reason why we have behaviors -igor On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Some useful design patterns like Decorator don't work with final methods. Wicket components sometimes have overridable factory methods for child components. The decorator pattern could be very useful here, because you'd be able to decorate the original component with some extra functionality (Link.onClick for example). Unfortunately this doesn't work because some methods are final. Matthijs Igor Vaynberg wrote: i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional com
Re: Making Component easier to Generify
Some useful design patterns like Decorator don't work with final methods. Wicket components sometimes have overridable factory methods for child components. The decorator pattern could be very useful here, because you'd be able to decorate the original component with some extra functionality (Link.onClick for example). Unfortunately this doesn't work because some methods are final. Matthijs Igor Vaynberg wrote: i mean generally, for methods, fields, and func args :) most of this stuff can stay final, but people dont bother doing it because its extra typing. -igor On Thu, Jun 12, 2008 at 8:38 AM, James Carman <[EMAIL PROTECTED]> wrote: You mean like C++? On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: indeed. i wouldnt mind if final was the default in java :) -igor On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Without the use of final wicket would not have made it this far. Martijn On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: I understand the reasoning, however I think "best practice" can be debated. To use your example Swing allows the user to override quite a bit, and it doesn't make any (or very few) assumptions on what should and should not be done. I don't like API's that assume I'm an idiot and prevent me from manipulating them how I see fit. If I cause a bug that I have to deal with, thats *my* problem to resolve. In my book (and I'm not the only one) excessive use of final is an anti-pattern. - Brill Pappin On 12-Jun-08, at 10:01 AM, cowwoc wrote: Brill, This is actually an API "best practice". Classes fall into two categories: ones designed for subclassing, and ones designed to be final. The same goes for methods. Swing is full of examples of what goes wrong when people override methods in classes that haven't been designed with subclassing in mind. Gili Brill Pappin wrote: on removing the finals The final members are the worst thing I've had to deal with in Wicket so far. Although I understand that there may be a reason for them, they are more a hinderance than anything else and seem to be trying to "protect users from themselves". - Brill Pappin On 12-Jun-08, at 1:03 AM, cowwoc wrote: Have you considered moving from subclassing to composition in Wicket using Callable? Currently it is quite common for developers to subclass a component in order to override isVisible() and other properties. I am proposing that instead the component classes become final and properties may only be set using setter methods. The setter methods would take Callable instead of T, so for example setVisible(boolean) would become setVisible(Callable) The benefit of this approach is that you could introduce static factory methods to the Wicket components which would make them much easier to use in their Generic form. You could then introduce various helper classes to create Callable for constant values, such as Callable.valueOf(true) would return a Callable that always returns true. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -
Re: enclosure around listview
Gwyn Evans wrote: On Wed, Jun 11, 2008 at 10:34 AM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Is there a way to hide a listview with an enclosure when there are no items to display? One way to get it working is to toggle the visibility of the listview based on wheter or not the list is empty or not. I think that's the normal way, in that you'd typically have both the list and a "No items found" label, then set one or the other as visible... I was expecting this would work out-of-the-box though... JIRA (https://issues.apache.org/jira/browse/WICKET) covers "Wishes" as well as "Bugs"! :-) /Gwyn I wish I knew what to wish for exactly... :D Thanks, Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
enclosure around listview
Hi, Is there a way to hide a listview with an enclosure when there are no items to display? One way to get it working is to toggle the visibility of the listview based on wheter or not the list is empty or not. I was expecting this would work out-of-the-box though... Thanks, Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ComponentPropertyModel
Hi,
CompoundPropertyModel does somewhat of the inverse of what I'm trying to
accomplish.
CompoundPropertyModel binds some model to an expression that is the id
of a component, while ComponentPropertyModel binds the model of the
component that it is used in to some expression. In the first case you
get to choose the model, in the second case you get to choose the
expression. But, alas, it does not work. Now I just use normal
PropertyModels. I could write some ComponentProperyModel as I think it
should work, but no time for that now, unfortunately... :S
As a side note. I don't like using the wicket id's as property
expressions. It places a tight coupling between a component's markup and
the component's model. This may be okay when the model is the component
itself, but not when the model's object is a domain object (which may
change at any time during development. not to speak of changing markup).
Regards,
Matthijs
Maurice Marrink wrote:
In all my years i have never used the ComponentPropertyModel. I always
use the CompoundPropertyModel.
public class MyPanel extends Panel {
public MyPanel(String id, IModel model) {
super(id, new CompoundPropertyModel(model));
add(new Label("name"));
}
}
Maurice
On Tue, Jun 10, 2008 at 2:49 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
Hi,
I'm trying to use ComponentPropertyModel as a replacement of PropertyModel
in some cases. The javadoc leads me to beleave I can do:
public class MyPanel extends Panel {
public MyPanel(String id, IModel model) {
super(id, model);
//add(new Label("label", new PropertyModel(model, "name")));
add(new Label("label", new ComponentPropertyModel("name")));
}
}
..which would have the advantage that the model that is bound to the
component is taken when needed instead of a hard reference to the model
passed in as an argument to the constructor. This would allow the label to
still display the correct value even when myPanel.setModel(..) is called
after constructing MyPanel.
Unfortunately the ComponentPropertyModel always throws an
IllegalStateException because the 'wrapped model' should have been used. I
don't know what that means exactly, but the classes where
ComponentPropertyModel is used call :
super(id);
setModel(wrap(model));
I'm not very in to wrap music, but it seems ComponentPropertyModel is not
doing what I want. What is the intended usage of ComponentPropertyModel?
Of course, the workaround is to not call myPanel.setModel, but
myPanel.setModelObject, so the reference to the component's model is
preserved. That way PropertyModel can be safely used.
Thanks,
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ComponentPropertyModel
Hi,
I'm trying to use ComponentPropertyModel as a replacement of
PropertyModel in some cases. The javadoc leads me to beleave I can do:
public class MyPanel extends Panel {
public MyPanel(String id, IModel model) {
super(id, model);
//add(new Label("label", new PropertyModel(model, "name")));
add(new Label("label", new ComponentPropertyModel("name")));
}
}
..which would have the advantage that the model that is bound to the
component is taken when needed instead of a hard reference to the model
passed in as an argument to the constructor. This would allow the label
to still display the correct value even when myPanel.setModel(..) is
called after constructing MyPanel.
Unfortunately the ComponentPropertyModel always throws an
IllegalStateException because the 'wrapped model' should have been used.
I don't know what that means exactly, but the classes where
ComponentPropertyModel is used call :
super(id);
setModel(wrap(model));
I'm not very in to wrap music, but it seems ComponentPropertyModel is
not doing what I want. What is the intended usage of ComponentPropertyModel?
Of course, the workaround is to not call myPanel.setModel, but
myPanel.setModelObject, so the reference to the component's model is
preserved. That way PropertyModel can be safely used.
Thanks,
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-extensions javadoc
I understand that the 1.2 docs must be on sf.net hardware, and that they are still available there. I just want the most recent version of the wicket-extensions javadoc to be available too, somewhere, anywhere. Doug did just that, so a big thanks there! Matthijs Martijn Dashorst wrote: wicketframework.org is not the main site. http://wicket.apache.org is As you can see, http://wicketframework.org redirects to http://wicket.apache.org The 1.2 docs are still available for reference, and *must* be hosted on the sf.net hardware (they are not released under supervision of Apache). Martijn On 5/7/08, Doug Donohoe <[EMAIL PROTECTED]> wrote: Matthijs, I had to host javadoc for my own wicketstuff-annotations project, so I decided to put the Wicket docs there (since the main site isn't up-to-date). I added wicket-extensions to the site: http://www.ddpoker.com/javadoc/ -Doug Matthijs Wensveen-2 wrote: > > Hi, > I'm not sure this is the right place, but anyway. The online javadoc of > wicket-extensions at > http://wicketframework.org/wicket-extensions/apidocs/index.html is of > version 1.2-SNAPSHOT, but the latest release is 1.3.3. The javadoc that > maven pulls in is more current. Could the online javadocs be updated > please? > > Thanks, > Matthijs > > -- > Matthijs Wensveen > Func. Internet Integration > W http://www.func.nl > T +31 20 423 > F +31 20 4223500 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/wicket-extensions-javadoc-tp17099232p17108936.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wicket-extensions javadoc
Hi, I'm not sure this is the right place, but anyway. The online javadoc of wicket-extensions at http://wicketframework.org/wicket-extensions/apidocs/index.html is of version 1.2-SNAPSHOT, but the latest release is 1.3.3. The javadoc that maven pulls in is more current. Could the online javadocs be updated please? Thanks, Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] wicketstuff-annotation 1.0 released
Doug Donohoe wrote: I am pleased to announce the 1.0 release of wicketstuff-annotation. Nice. But the name 'wicketstuff-annotation' does not say anything about what it does, just 'something with annotations'. IMO 'wicketstuff-mount-annotations' or somesuch would be better. Just my 2c. Matthijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: comunication between panels
Timo Rantalaiho wrote: On Mon, 18 Feb 2008, Mazzanti Luca wrote: i have a question: how can i comunicate between panels in wicket? The normal Wicket way is to share models, pass references etc, but it has its limitations. You can find an example of a push-type mechanism here https://issues.apache.org/jira/browse/WICKET-1312 though it is done with just one page in mind. This patch is almost what I want, cool! A question though: When sharing models between components, or using PropertyModels on a shared model, I would like to have onModelChanged events when something in that model changes. That way Components that use the model could use the onModelChanged method to add themselves to the AjaxRequestTarget (using AjaxRequestTarget.get() or (RequestCycle.get().getRequestTarget() instanceof AjaxRequestTarget) in wicket-1.2.x). Unfortunalety onModelChanged is only called when a model or model object is explicitly set on a component. Is there a way to make this more transparent? I was thinking along the lines of adding PropertyChangeSupport to all my model objects, but that would be very laborious. An aspect-oriented solution might do the trick too. Any ideas? Matthijs. -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Block second click
Ah, thanks for clearing that up.
In my case the processing has to be done once and only once, so
setEnabled(true) need not be called. After successful processing
setResponsePage(..) is called. So this should still work just for me,
right? I'll try tomorrow. If that doesn't work, I'll look at JS solutions.
Thanks for all the help,
Matthijs
Johan Compagner wrote:
this code doesn't work at all.
the onclick method isn't called at the same time by 2 request (2 link
clicks)
They are synchronized by wicket itself.
So what happens with the code below is that the first request sets the
enabled to false
then does the processing, then wicket blocks the second request in the mean
time
then the processing is finished, the link is enabled again. That request
does its processing rendering
after it is finished wicket will release the second request and that does
exactly the same thing as the first.
So the heavy stuff is always done twice, but it is done twice in sequence
If you don't want that then the only solution is to block the second click
in the browser using javascript magic.
johan
On Feb 6, 2008 5:12 PM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
On Wed, 06 Feb 2008, Matthijs Wensveen wrote:
I have a Link (not Ajax) on a component that does some heavyweight
processing in onClick. During this processing I want to block other
clicks from the same user. Is there a generic way to block multiple
requests on the same link? I would prefer a solution without Ajax /
JavaScript, but if that's impossible then that's okay.
Components are stateful, so maybe you could just keep the
state in your Link?
@Override onClick() {
if (!isEnabled()) {
return; // this shouldnt happen though?
}
try {
setEnabled(false);
doSomeHeavyWeightProcessing();
} finally {
setEnabled(true);
}
}
This creates a little race condition but if you can produce
it you could try using a real lock mechanism.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oyhttp://www.ri.fi/ >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Block second click
Martijn Dashorst wrote:
On 2/7/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
The if(!isEnabled()) will happen though, because the link is not really
disabled on the client side, but it does prevent
doSomeHeavyWeightProcessing to be called the second time which is what I
need.
The problem is that the href of the link points to the old version of
the page, and that has the link still enabled.
Martijn
Okay, so that won't prevent doSomeHWProc. Would a private member
variable do the trick? Following the same logic, I'd say no.
Any ideas as to how this could be done? A session scope variable
probably, but that would be *very* ugly. Is there a scope beyond the
versioned page but smaller than the session? Page-global or something
like that?
Hmm... does the version of the page that the link points to really have
the link enabled? Isn't that version the same version that is doing the
processing? And before that, setEnabled(false) is called... The same
goes for the private member variable trick. I'm wondering...
Thanks,
Matthijs.
What are the pros / cons of (ab)using setEnabled for this instead of
just a member variable)?
Thanks,
Matthijs
Timo Rantalaiho wrote:
On Wed, 06 Feb 2008, Matthijs Wensveen wrote:
I have a Link (not Ajax) on a component that does some heavyweight
processing in onClick. During this processing I want to block other
clicks from the same user. Is there a generic way to block multiple
requests on the same link? I would prefer a solution without Ajax /
JavaScript, but if that's impossible then that's okay.
Components are stateful, so maybe you could just keep the
state in your Link?
@Override onClick() {
if (!isEnabled()) {
return; // this shouldnt happen though?
}
try {
setEnabled(false);
doSomeHeavyWeightProcessing();
} finally {
setEnabled(true);
}
}
This creates a little race condition but if you can produce
it you could try using a real lock mechanism.
Best wishes,
Timo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Block second click
Hi,
The if(!isEnabled()) will happen though, because the link is not really
disabled on the client side, but it does prevent
doSomeHeavyWeightProcessing to be called the second time which is what I
need.
What are the pros / cons of (ab)using setEnabled for this instead of
just a member variable)?
Thanks,
Matthijs
Timo Rantalaiho wrote:
On Wed, 06 Feb 2008, Matthijs Wensveen wrote:
I have a Link (not Ajax) on a component that does some heavyweight
processing in onClick. During this processing I want to block other
clicks from the same user. Is there a generic way to block multiple
requests on the same link? I would prefer a solution without Ajax /
JavaScript, but if that's impossible then that's okay.
Components are stateful, so maybe you could just keep the
state in your Link?
@Override onClick() {
if (!isEnabled()) {
return; // this shouldnt happen though?
}
try {
setEnabled(false);
doSomeHeavyWeightProcessing();
} finally {
setEnabled(true);
}
}
This creates a little race condition but if you can produce
it you could try using a real lock mechanism.
Best wishes,
Timo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Block second click
Hello, I have a Link (not Ajax) on a component that does some heavyweight processing in onClick. During this processing I want to block other clicks from the same user. Is there a generic way to block multiple requests on the same link? I would prefer a solution without Ajax / JavaScript, but if that's impossible then that's okay. Thanks, Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: can auto fire the ajaxLink onClick function without click on the link?
kenixwong wrote:
Hi
i wish once the page is load, it will auto pop up the modal window. From the
wicket example, the modal window will only display once the user click on
the ajaxLink. So, is there any solution to auto fire the onClick function
without click the ajax Link.?
my page constructor involved the modal window and the ajaxLink:
final ModalWindow cancelModal = new ModalWindow("cancelModal ");
cancelModal .setPageMapName("cancelModal ");
cancelModal .setCookieName("cancelModal ");
cancelModal .setResizable(false);
cancelModal setInitialWidth(30);
cancelModal .setInitialHeight(12);
cancelModal .setWidthUnit("em");
cancelModal .setHeightUnit("em");
cancelModal .setPageCreator(new ModalWindow.PageCreator()
{
public Page createPage()
{
return new
CancelModal Page(CurrentPage.this);
}
});
add(cancelModal );
cancelModal .setOutputMarkupId(true);
add(link = new AjaxLink("cancelReportModalLink")
{
public void onClick(AjaxRequestTarget target)
{
triggerTarget = target;
cancelReportModal.show(target);
}
});
// is there i wrote in this way, the onClick function will fire once
the page is load
link.onClick(triggerTarget);
can anyone give help ? or any idea on it...
thanks in advance
You only need an AjaxRequestTarget, not necessarily from onClick. You
might add an AbstractAjaxTimerBehavior to cancelReportModal and then in
onTimer(ART t) { target.add(cRM); cRM.show(t); this.stop(); /* you only
want this once */ }
Or something alike (if it doesn't work, maybe add the behavior to the
container or something)
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to read the properties file in wicket?
Rama-o-Rama wrote: Hello, I am trying to read the property file like test.properties in the wicket. I have done previously like servletcontext.getresouceasstream(). what is the wicket way of reading the file. ~Rama If the properties file 'belongs' to a Component, like MyComponent.properties, I'd recommend using PackageResource. To load a Properties object you would do Properties.load(PackageResouce.get(MyComponent.class, "MyComponent.properties").getResourceStream().getInputStream())); I think using an IResourceStream implementation is more wickety than getting the servlet context. Only use javax.servlet.* classes when you really really need them. Who knows, maybe one day someone implements wicket on top of AWT (crazy but probably possible) and then you're in trouble (not really, but you get the point right?). BTW, you can get a resource from any Class or ClassLoader instance, so you could also do this.getClass().getClassLoader().getResouceAsStream(..) but I would still recommend PackageResource. Cheers, Matthijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to dynamically generate HTML page?
Hi Praveen,
Attached is the AutoComponentPanel.java. I've just re-written it so that
it implements IComponentResolver.
Parts of the code might be too complex and need to be refactored (some
parts working with org.w3c.dom), but for now it works. If you have
additions or modifications, please let me know. We plan to release this
code anyway either as part of a Qti framework, or just this panel as
part of some wicket-contrib / wicketstuff project.
Matthijs
PS. Wouter has uploaded his slides to slideshare:
http://www.slideshare.net/Func/wicket-dynamic-components
Pen wrote:
Thanks Matthijs,
I got a chance to look at Wouter Huijnink slides. This is what exactly I am
looking. Can you please forward the AutoComponentPanel code. That would be
great.
~Praveen
Matthijs Wensveen-2 wrote:
Hello Praveen,
Wouter Huijnink presented something similar to what you need at the
wicket meetup in Amsterdam. We generate html dynamically from xml, using
xslt. A component called AutoComponentPanel parses the html and adds
components to the hierarchy accordingly. This is actually a two-step
process. The first step is telling wicket you want to supply markup
yourself instead of letting wicket read it from the corresponding html
file. You can do this by implementing IMarkupResourceStreamProvider and
if applicable also IMarkupCacheKeyProvider. Then you need to parse the
markup stream and add components.
If you're interested I can send the AutoComponentPanel code. It still
needs some work to make it shine, but we plan to open source it anyway
as part of a wicket-based QTI framework.
PS. Unfortunately Wouter's slides aren't uploaded yet.
Pen wrote:
thanks Johan for your reply. I did take look into your slides.
We can generate HTML pages, we have no issue with it. But how to display
this newly created HTML pages which only exists in memory, there is no
physical file. And also to navigate to this new HTML page.
For example If I create a simple HTML page at runtime like below
test.html.
How to display it and navigate to it. As it also requires corresponding
test.java. This is simple one. But what if we have wicket:Ids we need
construct the Java files with all the action listener also.
test.html
Hello world!
~Praveen
Johan Compagner wrote:
Generate on one side the html by a servlet or special template
generator, that reads in your db data and generate the component
structure on the other side.
Look at he slides i put on of the presentation that i did for the
wicket user group in the netherlands
2007/12/4, Pen <[EMAIL PROTECTED]>:
I looked into the example wicketstuff-crud, this is basically in memory
database with basic CRUD operation. this is not what exactly I am
looking.
Let me restate the question. We have application where in user can
create
a
webpages using web designer by drag-n-drop where is html elements like
text,
image, selection box, combo box and save it in DB.
It will be Json format parse it to POJO and store in DB. for example
Image
object looks like this
which has got position, style, etc .
[{"position":({left:60, top:40}),
"size":({width:100,height:80}),
"positionTop":40,"positionLeft":60,"sizeWidth":100,"sizeHeight":80,
"cssClass":"",
"style":"left:60px;top:40px;width:100px;height:80px;",
]}}]})
Now we need to read from the DB and reconstruct the same Image object
has
a
html page. We can construct the above object with HTML tags.
But the question is how to display this html pages, since it exists
only
in
memory and also how to navigate to this newly created page.
~Praveen
igor.vaynberg wrote:
see how wicketstuff-crud does it in wicket-stuff svn
-igor
On Dec 3, 2007 6:30 PM, Pen <[EMAIL PROTECTED]> wrote:
I am a new wicker user. We need to construct/generate a HTML page
dynamically at runtime from the HTML elements like image and text.
This
page only exists in memory(session/cache) and there is no physical
file.
so
how to generate such page and corresponding java class. How this can
be
done
for static elements like image and text versus dynamically for form
submit.
Also how to navigate to this newly generated html page.
~Praveen
--
View this message in context:
http://www.nabble.com/How-to-dynamically-generate-HTML-page--tf4940771.html#a14143413
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IComponentResolver question
Igor Vaynberg wrote: icomponentresolver does exactly what its javadoc says - match markup tags to components. if you want you can create those components on the fly - but remember that this happens at render time so it might have some side effects for you. The javadoc mentions "component names", but you can create components based on anything of the ComponentTag. Would "IComponentResolvers are responsible for mapping ComponentTags to Wicket components." be a better description? Of course, you don't even have to look at the component tag to create a component (i.e. RandomComponentResolver) but that would be pretty useless :) you dont need to rewrite your panel as a component resolver and add it to application settings - not many global component resolvers make sense unless you use namespaced markup tags. instead it is most times easier to simply let your component implement the interface directly - it works that way too. Okay, that's good to know. I'll do that. Do I need to add the created component to the container with container.autoAdd() ? if you want to see how it is meant to be used then simply search our codebase for references to it. I did do that, but I was unsure whether or not to use it myself. Thanks for the explanation, Matthijs -igor On Dec 5, 2007 7:15 AM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Hello, I have developed a panel named AutoComponentPanel that automatically adds wicket components based on (dynamic) markup. Looking at IComponentResolver I noticed some similarities. Can someone explain this class and its uses to me? Is it something that I should want to use for AutoComponentPanel? We use AutoComponentPanel as a base class for some other panels that provide dynamic markup. For example transformed xml (xml -> xslt -> xhtml + wicket:id attributes). Would it be better (aka the wicket-way (tm)) when AutoComponentPanel is re-written as an IComponentResolver that can be used by the currently subclassing panels? They would then need to implement IComponentResolver too but can call my rewritten AutoComponentPanelAsResolverSomething in their implementing methods. Would this be a better way to go? How should this work when I add my resolver with Application.getPageSettings().addComponentResolver(resolver)? Thanks, Matthijs Wensveen -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IComponentResolver question
Hello, I have developed a panel named AutoComponentPanel that automatically adds wicket components based on (dynamic) markup. Looking at IComponentResolver I noticed some similarities. Can someone explain this class and its uses to me? Is it something that I should want to use for AutoComponentPanel? We use AutoComponentPanel as a base class for some other panels that provide dynamic markup. For example transformed xml (xml -> xslt -> xhtml + wicket:id attributes). Would it be better (aka the wicket-way (tm)) when AutoComponentPanel is re-written as an IComponentResolver that can be used by the currently subclassing panels? They would then need to implement IComponentResolver too but can call my rewritten AutoComponentPanelAsResolverSomething in their implementing methods. Would this be a better way to go? How should this work when I add my resolver with Application.getPageSettings().addComponentResolver(resolver)? Thanks, Matthijs Wensveen -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IComponentResolver question. Was: How to dynamically generate HTML page?
I was looking at the code of AutoComponentPanel and found similarities
between this and IComponentResolver. AutoComponentPanel has an
overridable getMarkupComponent(ComponentTag, MarkupStream) where
IComponentResolver has resolve(MarkupContainer, MarkupStream,
ComponentTag). Can someone explain this class and its uses to me? Is it
something that I should want to use for AutoComponentPanel?
We user AutoComponentPanel as a base class for some other panels that
provide dynamic markup. Would it be better (aka the wicket-way (tm))
when AutoComponentPanel is re-written as an IComponentResolver that can
be used by the currently subclassing panels. They would then need to
implement IComponentResolver too but can call my rewritten
AutoComponentPanelAsResolverSomething in their implementing methods.
Would this be a better way to go?
How should this work when I add my resolver with
Application.getPageSettings().addComponentResolver(resolver)?
Thanks,
Matthijs Wensveen
Matthijs Wensveen wrote:
Hello Praveen,
Wouter Huijnink presented something similar to what you need at the
wicket meetup in Amsterdam. We generate html dynamically from xml,
using xslt. A component called AutoComponentPanel parses the html and
adds components to the hierarchy accordingly. This is actually a
two-step process. The first step is telling wicket you want to supply
markup yourself instead of letting wicket read it from the
corresponding html file. You can do this by implementing
IMarkupResourceStreamProvider and if applicable also
IMarkupCacheKeyProvider. Then you need to parse the markup stream and
add components.
If you're interested I can send the AutoComponentPanel code. It still
needs some work to make it shine, but we plan to open source it anyway
as part of a wicket-based QTI framework.
PS. Unfortunately Wouter's slides aren't uploaded yet.
Pen wrote:
thanks Johan for your reply. I did take look into your slides.
We can generate HTML pages, we have no issue with it. But how to display
this newly created HTML pages which only exists in memory, there is no
physical file. And also to navigate to this new HTML page.
For example If I create a simple HTML page at runtime like below
test.html.
How to display it and navigate to it. As it also requires corresponding
test.java. This is simple one. But what if we have wicket:Ids we need
construct the Java files with all the action listener also.
test.html
Hello world!
~Praveen
Johan Compagner wrote:
Generate on one side the html by a servlet or special template
generator, that reads in your db data and generate the component
structure on the other side.
Look at he slides i put on of the presentation that i did for the
wicket user group in the netherlands
2007/12/4, Pen <[EMAIL PROTECTED]>:
I looked into the example wicketstuff-crud, this is basically in
memory
database with basic CRUD operation. this is not what exactly I am
looking.
Let me restate the question. We have application where in user can
create
a
webpages using web designer by drag-n-drop where is html elements like
text,
image, selection box, combo box and save it in DB.
It will be Json format parse it to POJO and store in DB. for example
Image
object looks like this
which has got position, style, etc .
[{"position":({left:60, top:40}),
"size":({width:100,height:80}),
"positionTop":40,"positionLeft":60,"sizeWidth":100,"sizeHeight":80,
"cssClass":"",
"style":"left:60px;top:40px;width:100px;height:80px;",
]}}]})
Now we need to read from the DB and reconstruct the same Image
object has
a
html page. We can construct the above object with HTML tags.
But the question is how to display this html pages, since it exists
only
in
memory and also how to navigate to this newly created page.
~Praveen
igor.vaynberg wrote:
see how wicketstuff-crud does it in wicket-stuff svn
-igor
On Dec 3, 2007 6:30 PM, Pen <[EMAIL PROTECTED]> wrote:
I am a new wicker user. We need to construct/generate a HTML page
dynamically at runtime from the HTML elements like image and
text.
This
page only exists in memory(session/cache) and there is no physical
file.
so
how to generate such page and corresponding java class. How this can
be
done
for static elements like image and text versus dynamically for form
submit.
Also how to navigate to this newly generated html page.
~Praveen
--
View this message in context:
http://www.nabble.com/How-to-dynamically-generate-HTML-page--tf4940771.html#a14143413
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to dynamically generate HTML page?
Hello Praveen,
Wouter Huijnink presented something similar to what you need at the
wicket meetup in Amsterdam. We generate html dynamically from xml, using
xslt. A component called AutoComponentPanel parses the html and adds
components to the hierarchy accordingly. This is actually a two-step
process. The first step is telling wicket you want to supply markup
yourself instead of letting wicket read it from the corresponding html
file. You can do this by implementing IMarkupResourceStreamProvider and
if applicable also IMarkupCacheKeyProvider. Then you need to parse the
markup stream and add components.
If you're interested I can send the AutoComponentPanel code. It still
needs some work to make it shine, but we plan to open source it anyway
as part of a wicket-based QTI framework.
PS. Unfortunately Wouter's slides aren't uploaded yet.
Pen wrote:
thanks Johan for your reply. I did take look into your slides.
We can generate HTML pages, we have no issue with it. But how to display
this newly created HTML pages which only exists in memory, there is no
physical file. And also to navigate to this new HTML page.
For example If I create a simple HTML page at runtime like below test.html.
How to display it and navigate to it. As it also requires corresponding
test.java. This is simple one. But what if we have wicket:Ids we need
construct the Java files with all the action listener also.
test.html
Hello world!
~Praveen
Johan Compagner wrote:
Generate on one side the html by a servlet or special template
generator, that reads in your db data and generate the component
structure on the other side.
Look at he slides i put on of the presentation that i did for the
wicket user group in the netherlands
2007/12/4, Pen <[EMAIL PROTECTED]>:
I looked into the example wicketstuff-crud, this is basically in memory
database with basic CRUD operation. this is not what exactly I am
looking.
Let me restate the question. We have application where in user can create
a
webpages using web designer by drag-n-drop where is html elements like
text,
image, selection box, combo box and save it in DB.
It will be Json format parse it to POJO and store in DB. for example
Image
object looks like this
which has got position, style, etc .
[{"position":({left:60, top:40}),
"size":({width:100,height:80}),
"positionTop":40,"positionLeft":60,"sizeWidth":100,"sizeHeight":80,
"cssClass":"",
"style":"left:60px;top:40px;width:100px;height:80px;",
]}}]})
Now we need to read from the DB and reconstruct the same Image object has
a
html page. We can construct the above object with HTML tags.
But the question is how to display this html pages, since it exists only
in
memory and also how to navigate to this newly created page.
~Praveen
igor.vaynberg wrote:
see how wicketstuff-crud does it in wicket-stuff svn
-igor
On Dec 3, 2007 6:30 PM, Pen <[EMAIL PROTECTED]> wrote:
I am a new wicker user. We need to construct/generate a HTML page
dynamically at runtime from the HTML elements like image and text.
This
page only exists in memory(session/cache) and there is no physical
file.
so
how to generate such page and corresponding java class. How this can
be
done
for static elements like image and text versus dynamically for form
submit.
Also how to navigate to this newly generated html page.
~Praveen
--
View this message in context:
http://www.nabble.com/How-to-dynamically-generate-HTML-page--tf4940771.html#a14143413
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/How-to-dynamically-generate-HTML-page--tf4940771.html#a14156946
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Yes Stefan, I would think that would be a better approach to use a new set of
tags. It also allows you to choose more correct naming (because inheritance
isn't actually a parent/child relationship so the word child just confuses the
issue).
Maybe wicket:abstract in the base and wicket:implements (nice - thanks to
whoever suggested that) or wicket:override in the derived (extended) markup.
I think using IDs up front would also be great, if not necessary, because in
Java as would probably occur in wicket mark up, you can have intermediate
classes that don't implement all abstract methods in a base class. Without IDs
you won't know exactly which abstract method an intermediate class is
implementing.
This example hopefully demonstrates what I mean:
Base
PumpsBase
-
A header for all pages to do with pumps
Note: no body implemented here - deferred until a more specialized
class/markups: WaterPumpsBase and OilPumpsBase
WaterPumpBase
-
Note: no header implemented here - the general PumpsBase one suffices for all
pumps pages
A body discussing water pumps
OilPumpBase
---
Note: no header implemented here - the general PumpsBase one suffices for all
pumps pages
A body discussing oil pumps
I think the tag pairs abstract/implements flow much better from an OO
perspective than child/extends. It hurts my brain way to much to think of a
base class as a child.
Wouldn't this essentially be the same as using id="header"/> and using WebMarkupContainers on the java side?
I.e.:
Base
PumpsBase
-
A header for all pages to do with pumps
Note: no body implemented here - deferred until a more specialized
class/markups: WaterPumpsBase and OilPumpsBase
WaterPumpBase
-
Note: no header implemented here - the general PumpsBase one suffices
for all pumps pages
A body discussing water pumps
OilPumpBase
---
Note: no header implemented here - the general PumpsBase one suffices
for all pumps pages
A body discussing oil pumps
On the java side you'd have to addOrReplace(new
WebMarkupContainer("header")) but it's essentially the same. Or am I
missing some point?
I think the power of wicket lies in its component-based approach and not
(necessarily) in its OO features.
Matthijs
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing IDEs to eclipse
Double-click the server, click the modules tab, uncheck 'enable reloading' on the module that is the project you are working on. BTW, I use Eclipse and Maven and it just works great together. Unfortunately there is no support for WTP 2.0 yet for the maven eclipse (or should I say eclipse maven) plugin. So everyone, go nag at: http://jira.codehaus.org/browse/MECLIPSE-264 Matthijs Johan Maasing wrote: However, I just downloaded the latest Eclipse (OSX/ for Java EE, see http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/20070927/eclipse-jee-europa-fall-macosx-carbon.tar.gz) and ran it on a new workspace. By default, only *.launch is being filtered. Those other resources must be added by a plugin is what I suspect. I have the same experience with using Tomcat in WTP. Clean install of J2EE-Europa (Eclipse 3.3). Created a new dynamic web-project. Put the required wicket JARs in lib, configure the http-filter and it just works. Eclipse does not filter the html files. It does redeploy the entire app when a file changes (instead of hot swapping only the changed files) but that is ok for my small project. All this without having to install the user friendly maven ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Link embedded in localized Label/Message?
The problem is that you want the link to appear within the localized
message, right?
The easy way is to split the localized message into 3 parts: a localized
part before the link, a localized link label and a localized part after
the link. This is a little cumbersome but works without much hassle.
If you need this a lot, you could write a component that parses the
localized string to generate it's own markup (replace all {myLink} with
) and then add the link to that component. This is
not very easy to do but can save time if you need it a lot.
Matthijs.
Thies Edeling wrote:
Hi,
In your HTML the label is a child of the link so do it the other way
around, add the label to the link
Link l = new Link..
l.add(new Label..
with
gr
Thies
Hi,
is it possible to have a link in a localized label?
I would like to have something like this in my output:
Please click here. And then do
--> Is there a possiblity to use a StringResourceModel here?
Something like
pagexyz.usermessage=Please click {mylink}. And then do...
How would I now add the link to the message?
myLabel.add( new Link( does not work...
If this is not possible, how is the standard way of doing such a thing?
Thanks for your help!
Marcus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: enable / disable MarkupContainer and all children
-bump- Summary: how to disable a component and all of its children in one call? And also: what is the expected behavior of a disabled parent component in the light of its children? A quick look in the source of FormComponentPanel tells me that this code does not disable or enable its children when it itself is disabled or enabled. Matthijs PS. The onBeforeRender implementation I have (uses IVisitor to disable children) works well enough. This mail is just because I'm curious how this should be done. Matthijs Wensveen wrote: Hi, I have a Panel (myPanel) containing some child components. When I say: myPanel.setEnabled(false); I want to disable the panel, but also disable all children. Preferably, I'd override setEnabled, but since it is final (sigh), this is impossible. A less elegant way to do it is to supply a public setChildrenEnabled method, or something. Usually, the applications I build try to be as implementation-agnostic as possible regarding the specific component subclasses, i.e. declare myPanel as Panel or even Component where possible. In that case, classes that use myPanel don't see setChildrenEnabled unless they cast it to MyPanel. Another way would be to override onBeforeRender and use a Component.IVisitor to call setEnabled on all children. This works, but seems to me like the wrong moment to do this. Also, it would not allow you to disable myPanel but enable some specific child (since that would be overruled in onBeforeRender of MyPanel). I think it comes down to the semantics of setEnabled. What does it mean when a component is disabled? What does it mean to a child when its parent is disabled? (this is starting to sound like a charity ad.) Anyways. Any ideas? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
enable / disable MarkupContainer and all children
Hi, I have a Panel (myPanel) containing some child components. When I say: myPanel.setEnabled(false); I want to disable the panel, but also disable all children. Preferably, I'd override setEnabled, but since it is final (sigh), this is impossible. A less elegant way to do it is to supply a public setChildrenEnabled method, or something. Usually, the applications I build try to be as implementation-agnostic as possible regarding the specific component subclasses, i.e. declare myPanel as Panel or even Component where possible. In that case, classes that use myPanel don't see setChildrenEnabled unless they cast it to MyPanel. Another way would be to override onBeforeRender and use a Component.IVisitor to call setEnabled on all children. This works, but seems to me like the wrong moment to do this. Also, it would not allow you to disable myPanel but enable some specific child (since that would be overruled in onBeforeRender of MyPanel). I think it comes down to the semantics of setEnabled. What does it mean when a component is disabled? What does it mean to a child when its parent is disabled? (this is starting to sound like a charity ad.) Anyways. Any ideas? -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to forward request to an external URL
For completeness sake: http://cwiki.apache.org/WICKET/how-to-redirect-to-an-external-non-wicket-page.html Igor Vaynberg wrote: requestcycle.setrequesttarget(new redirectrequesttarget(url)); -igor On 10/9/07, Nili Adoram <[EMAIL PROTECTED]> wrote: Hi all, Suppose I want to forward the HTTP request to some external url (NOT a wicket page, e.g. a JSP page). I want to end the request cycle at this point ( not include this URL inside my page). How can I simulate request.getRequestDispatcher(url).forward() within a wicket page? Thanks Nili -- 10x, Nili Adoram - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new class reloading solution JavaRebel
Looks promising. A lot of people here complain about having to restart jetty or tomcat every time they modify their classes. Too bad it's commercial :( Eelco Hillenius wrote: Hi people, I haven't tried it myself yet, but Jevgeni Kabanov (from Aranea framework[1]) just released 'JavaRebel' which is a transparent class loading solution. It should work well with Wicket, since Wicket is a pure Java framework. Jevgeni is interested in user experiences and he'd like to write an article about Wicket + JavaRebel if he gets a few confirmations of people successfully using it. Read more about it here: http://www.zeroturnaround.com/blog/javarebel-brings-class-reloading-to-java/, and let us (this list or Jevgeni) know what your experiences are. Have fun! Eelco [1] http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwww.araneaframework.org%2F&ei=p5kLR_7lHZPEepmm4ZwF&usg=AFQjCNGZ2m5UshrHFf0T40HjEF0nOCE8iA&sig2=0oAqqHaBEuy2rC256-8t_Q - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A button that does NOT submit form?
Most (if not all) browsers, whether text-based or graphically, support
submitting of forms, regardless of what the server does with the
submitted information. On the other hand, not all browsers (fully)
support javascript. So in my opinion a button that submits a form but
does nothing with that data is better that a button that uses javascript
to emulate a link. I did not say *anything* about using a real link,
that is,
So if you want a *button* that does what the original poster wants, use
setDefaultFormProcessing(false), but you might want to consider using a
link proper.
And yes, let's talk accessibility, it's very important for some people.
When it's possible to make an app that works for both groups with a
little bit of extra effort, do so. Provided, of course, there is time
(and money) to do so.
Matthijs.
BTW: Do we like top-posting or bottom-posting? I really don't care, but
if there is a convention (as some mailing lists have), I'll conform to that.
Igor Vaynberg wrote:
if you are going to start talking accessibility then that link should
be an anchor period, not a button. buttons are bad if you do not need
a form-submit :)
-igor
On 10/7/07, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
Al Maw wrote:
Stanczak Group wrote:
I don't want the cancel button to submit the form, is this the best
method? I'm not sure I see how to do this. Is there examples?
@Override
protected void delegateSubmit(IFormSubmittingComponent
component) {
}
Also have a look at Button#setDefaultFormProcessing(false);
Regards,
Al
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Button.setDefaultFormProcessing does submit the form (in the HTTP sense)
but the form's model is not updated. I think this is a better solution
because it doesn't require javascript (a Link on a element
generates onclick), and thus more accessible.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A button that does NOT submit form?
Al Maw wrote:
Stanczak Group wrote:
I don't want the cancel button to submit the form, is this the best
method? I'm not sure I see how to do this. Is there examples?
@Override
protected void delegateSubmit(IFormSubmittingComponent
component) {
}
Also have a look at Button#setDefaultFormProcessing(false);
Regards,
Al
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Button.setDefaultFormProcessing does submit the form (in the HTTP sense)
but the form's model is not updated. I think this is a better solution
because it doesn't require javascript (a Link on a element
generates onclick), and thus more accessible.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing html-template programmatically?
wfaler wrote: Hi, Is it possible to change the default html-template file loaded for a class programmatically (for instance, changing from a classpath file, to a file in another file-directory)? For instance, if I want to change the underlying html-template on the fly, but keeping the same component hierarchy? Regards Wille Hi Wille, You can implement IResourceStreamLocator and set an instance of that on your application: myApplication.getResouceSettings().setResourceStreamLocator(myResourceStreamLocator); You can then return an IResourceStream from any source you might have (another directory, a database, anything) A nifty trick (I think) is to use the locator that is already set on the application to fall back to when your locator can't find the requested resource, but that is up to you and your requirements. When you don't want to set a IResourceStreamLocator globally, but just for a component, you can have that component implement IMarkupResourceStreamProvider (and preferably also IMarkupCacheKeyProvider). This way you can return a desired IResourceStream based on some model property if you like. Be careful that you do add the required components to your hierarchy. This is especially true when you generate markup dynamically. Also, take a look at the custom template / resource loading examples at: http://wicketstuff.org/wicket13/customresourceloading/ BTW, does anyone know what the purpose of application.getResourceSettings().getResourceFinder() is? Regards, Matthijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to add dynamically typed form components?
Eelco Hillenius wrote: Any thoughts on the viability of this approach? Any alternative approaches? Sounds complicated. But if you want to preserve the markup of your source file, using xsl might be the way to go. An alternative or additional tech is to create custom wicket tag handles (e.g. to handle ) that dynamically inserts (auto)components in those spots. Look at the existing ones for ideas. Or you could just use a factory for building your form dynamically using the XML file as input. But that would only work well if you don't want to preserve your markup (e.g when you'd only have 'interaction' regions and maybe a very limited set of primitives for defining layout such as , etc) Eelco Hi, The markup comes from a database and can be seen as content rather than structure. So the first experiment we did was to implement IMarkupResourceStreamProvider so we could supply markup form a different source then the source html file, namely the model (or a property thereof). This works like a charm and opens up all kinds of dynamic component stuff. The wicket:interaction idea is kind of the same as what we suggested but then using specialized tags for our purpose, right? I'll look into that as it sounds like a possible option. I don't quite understand how the factory in your 2nd suggestion would work. I see two problems. 1: The factory creates a component that we add to the hierarchy, but it should also be referenced in the markup. I think we might work around this by using panels, because they have their own markup. 2: I see a problem with the nested nature of the input xml. We'd have to insert snippets of ill-formed xml as labels into the hierarchy. This is something the factory could do of course but feels 'just wrong'. I said in another mail in this thread (parallel to this mail) that parsing the xml in java code is harder than using xslt. If I understand the factory suggestion correctly, this would problem would still remain. Thanks and regards (to all), Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to add dynamically typed form components?
Okay, I took a look at the the ws-crud project and I think the main
difference is that ws-crud works on a flat list of properties, so you
can use a listview to add panels that are appropriate for the type of
property you want to crud (TextEditor etc), whereas what we want to do
is deeply nested (see Wouter's example).
We'd need to parse up to
some silly info here
Insert that using a Label or a Panel containing a Label or something.
Then insert a TextField (or a Panel containing..) for
[custom stuff for this
namespace]
Then keep on parsing:
even more info here, and a nested element:
This might all be possible but has a few drawbacks:
1. We're inserting Labels with ill-formed xhtml. It will become well
formed again when the parsing and inserting is done but it feels very
dirty (in a bad way).
2. Parsing and examining the x(ht)ml in java code is hard, especially
the somenamespace:interaction elements. Using xslt to transform to
meaningful xhtml is *much* easier.
The proof-of-concepts we have done with our method have proven
successful so far, but we like to do things 'the wicket way'. That is;
if there is a solution within the framework, use that.
Igor Vaynberg wrote:
see wicketstuff-crud project in wicket-stuff svn. that should give you all
the good ideas.
-igor
On 9/25/07, Wouter Huijnink <[EMAIL PROTECTED]> wrote:
Hi list,
I've seen some threads on dynamically adding components to a form, but
those mainly concern a dynamic *number* of components of the same type.
Our use case concerns adding dynamically typed components to a form. The
idea is as follows:
We have XML consisting of XHTML elements and optional nested xml
elements from another namespace - something like:
some silly info here
[custom stuff for this
namespace]
even more info here, and a nested element:
[custom stuff for this
namespace]
What we want to achieve, is to create a (Form?)Component subclass that
can add a FormComponent to itself (or to the form?) for each
interaction, where the actual component created depends on the 'type '
attribute of the interaction.
So the xml snippet should in the end be displayed in the user's browser
as:
some silly info here
even more info here, and a nested element:
Our thoughts on this:
1. Transform the XML to wicket markup. Temporary result:
some silly info here
even more info here, and a nested element:
2. Feed this markup to a Panel subclass that overriding
getMarkupResourceStream()
The panel overrides getMarkupResourceStream thus:
public IResourceStream getMarkupResourceStream(MarkupContainer
container,
Class containerClass) {
String markup = String.format("%s",
getModelObject());
return new StringResourceStream(markup);
}
In the constructor of this panel the provided wicket markup is set as
its model, and the associated markup stream is iterated to dynamically
add form components backing the generated input tags:
public MarkupProvidingPanel(String id, IModel model) {
// model contains a modelObject of type String containing wicket
markup
super(id, model);
final MarkupStream associatedMarkupStream =
getAssociatedMarkupStream(false);
while(associatedMarkupStream.hasMore()) {
MarkupElement element = associatedMarkupStream.next();
if (element instanceof ComponentTag) {
ComponentTag componentTag = (ComponentTag) element;
if ("input".equals(componentTag.getName())) {
String type =
componentTag.getAttributes().getString("type", "text");
if ("text".equals(type)) {
add(new TextField(componentTag.getId()));
} else if ("submit".equals(type)) {
add(new Button(componentTag.getId(), new
Model("do it!")));
}
}
}
}
}
Any thoughts on the viability of this approach? Any alternative
approaches?
Regards,
Wouter
--
Wouter Huijnink
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to add dynamically typed form components?
Without looking into the wicketstuff-crud project (yes, I'm lazy), can
you please enlighten us a bit? Is Wouters idea below valid and workable
or is he entirely mad!? ;)
Is wicketstuff-crud going about it in an entirely different way?
Matthijs
Igor Vaynberg wrote:
see wicketstuff-crud project in wicket-stuff svn. that should give you all
the good ideas.
-igor
On 9/25/07, Wouter Huijnink <[EMAIL PROTECTED]> wrote:
Hi list,
I've seen some threads on dynamically adding components to a form, but
those mainly concern a dynamic *number* of components of the same type.
Our use case concerns adding dynamically typed components to a form. The
idea is as follows:
We have XML consisting of XHTML elements and optional nested xml
elements from another namespace - something like:
some silly info here
[custom stuff for this
namespace]
even more info here, and a nested element:
[custom stuff for this
namespace]
What we want to achieve, is to create a (Form?)Component subclass that
can add a FormComponent to itself (or to the form?) for each
interaction, where the actual component created depends on the 'type '
attribute of the interaction.
So the xml snippet should in the end be displayed in the user's browser
as:
some silly info here
even more info here, and a nested element:
Our thoughts on this:
1. Transform the XML to wicket markup. Temporary result:
some silly info here
even more info here, and a nested element:
2. Feed this markup to a Panel subclass that overriding
getMarkupResourceStream()
The panel overrides getMarkupResourceStream thus:
public IResourceStream getMarkupResourceStream(MarkupContainer
container,
Class containerClass) {
String markup = String.format("%s",
getModelObject());
return new StringResourceStream(markup);
}
In the constructor of this panel the provided wicket markup is set as
its model, and the associated markup stream is iterated to dynamically
add form components backing the generated input tags:
public MarkupProvidingPanel(String id, IModel model) {
// model contains a modelObject of type String containing wicket
markup
super(id, model);
final MarkupStream associatedMarkupStream =
getAssociatedMarkupStream(false);
while(associatedMarkupStream.hasMore()) {
MarkupElement element = associatedMarkupStream.next();
if (element instanceof ComponentTag) {
ComponentTag componentTag = (ComponentTag) element;
if ("input".equals(componentTag.getName())) {
String type =
componentTag.getAttributes().getString("type", "text");
if ("text".equals(type)) {
add(new TextField(componentTag.getId()));
} else if ("submit".equals(type)) {
add(new Button(componentTag.getId(), new
Model("do it!")));
}
}
}
}
}
Any thoughts on the viability of this approach? Any alternative
approaches?
Regards,
Wouter
--
Wouter Huijnink
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
Eelco Hillenius wrote: is it a joke ? In that case web design templates would need a unique class attribute for each element that is going to be used via Ajax. And in some cases it's not possible at all. For example, odd rows in a table might have a different color than even rows. Typically one kind of rows have the same class attribute. If wicket will use class attribute as an identifier then there will be no way to work with table rows. He said that as a user. The Wicket framework won't switch to using classes instead of ids of course :-) Eelco Phew, I also read that the wrong way. It'd been interesting to see though how you'd manage to keep Ajax working and all. Outputting the java class as html class might be nice though. It would be useful to style wicket components in css. But it's easy to do this yourself already. Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get a list of the connected users ?
landry soules wrote: Hello, I have to display a list of the connected users in a page of my app. I know it sounds definitely dumb, but i don't know how to achieve this... Users login to my site (i extended AuthenticatedWebApplication), and then i update a "isConnected" flag in users table. Thus i display the connected users in a list view, retrieved by the "isConnected" flag. It implies of course that users will use a "logoff" button when they leave, which i don't believe they will do... I'm aware it's not a Wicket related problem, but a more generally web apps problem, but what is the best solution to deal with this ? Thanks for your answers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If you don't want to tread on the lower-level servlet API, maybe you could do something with WebApplication.sessionDestroyed or ISessionStore.unbind. Although I'm not exactly sure when they are called (just browsing javadoc, that's all). Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any interest in a Wicket User Group meeting in The Netherlands?
Hi, I'm interested, and I think several of my co-workers are too. Matthijs Danny van Bruggen wrote: I'm interested. I've only just started, so every topic is helpful to me :) Amersfoort is fine for me. Danny On 9/7/07, Johan Compagner <[EMAIL PROTECTED]> wrote: hi, I can organize one if there is enough interest Martijn and i will be there then. And for example if people are also interested in the wicket security i will also drag Maurice to the table. johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form.updateFormComponentModels bug?
Johan Compagner wrote: The extra memory for the ClickListener is negligible and does give you more flexibility because now you can have more than one interested party for the link click. My use case (fetch nested component, add listener) was already answered sufficiently by Martijn (bad OO, components should publish own events that make sense in the problem domain), but I still an eventlistener-based design could have merit (see the move towards Delegation Event Model in AWT: http://java.sun.com/j2se/1.3/docs/guide/awt/designspec/events.html). While wicket is not swing or awt, it's an interesting read. with the link abstract class you don't have any extra memory overhead but with the listener interface you have quite a lot because you need and extra reference in link itself, that holds an extra List (that again has its own stuff) The trick in awt is to only hold one reference to a listener that recursively fires the event on registered listeners (see AWTEventMultiCaster) and then you have an extra instance of the listener itself which by itself has its internal representation Don't underestimate this. especially because we also can use them in tableviews with a lot of cells. But as i said, if you want a listener interface then you can build it quite easily True, but of course my goal is not to create a fork, but to discuss different views on the used event model. I'm not an expert on memory or profiling, so I'll believe you. I do think that such a choice should not only be made on the basis of memory usage. But since the choice is already made, I'll go with it until I can find a more convincing argument (although the link I supplied has some quite convincing ones). Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form.updateFormComponentModels bug?
Okay, I get the whole conversion is validation thingy. Not entirely
convinced whether validation is the only place where conversion should
take place, but I'll leave this subject for now. It's already a lot
clearer to me now.
We have this also because it preserves memory, If you have to make an
(inner)class instance
and a link instance and attach those 2 each other that can consume much
more
memory
then when just making a new class and have there one instance.
I'm not sure I see what you mean, but doesn't the (inner) class also
need instantiation, consuming just as much memory?
Yes but only 1 instance.. for example:
Link link = new Link()
{
onClick()
{
// do your thing
}
}
or
Link link = new Link();
link.add(new LinkClickListener()
{
onClick()
{
// do you thing.
}
});
the second approach makes 2 instances and link has now also a special extra
map to hold the listener.
johan
The extra memory for the ClickListener is negligible and does give you
more flexibility because now you can have more than one interested party
for the link click. My use case (fetch nested component, add listener)
was already answered sufficiently by Martijn (bad OO, components should
publish own events that make sense in the problem domain), but I still
an eventlistener-based design could have merit (see the move towards
Delegation Event Model in AWT:
http://java.sun.com/j2se/1.3/docs/guide/awt/designspec/events.html).
While wicket is not swing or awt, it's an interesting read.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: why final?
Martijn Dashorst wrote:
On 9/10/07, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
Off-topic: Why are so much methods marked final? This might prevent
API-misuse but also prevents innovative _use_! I can understand you want
framework users to do it the wicket way, because they will probably only
spam the users list with questions that have obvious solutions (like me
:D ). But sometimes it's just frustrating.
Innovative use is something we frown upon. Seriously: we *NEED* the
ability to be able to get stuff out of the way. Sometimes the hiding
capabilities of Java are not enough in a good OO hierarchy. When we
open up something to be overridable we do so *only* when we are
confident it will not break stuff. This gives us leeway to replace
parts of our api we aren't proud of (yes we are still learning) with
an api that is much better suited.
More from an old faq (I added it to our wiki):
Classes and methods in Wicket are generally declared as final until
the need for extensibility is well understood. While this defensive
approach may seem obsessive to some, the major benefit is that classes
and methods which haven't been designed for extension cannot be
extended until the problem(s) at hand are examined by the Wicket
development team. This helps to ensure that the best approach is
taken. Sometimes, straightforward extension is not the best approach.
Sometimes, features of the API have been misapplied or misunderstood.
It's best to catch this early.
While this does provoke more discussion and sometimes a bit of
annoyance, the discussion generally improves Wicket and will help
ensure greater backwards compatibility in the future. It's really a
matter of how the development team manages API commitments. By making
fewer commitments in the API in terms of extension points, we are more
likely to be able to support those extension points that we do allow
in the future. We are also more likely to catch anti-pattern use cases
and provide features appropriate to the problems you are trying to
solve.
Honestly, we aren't trying to annoy anyone and we do aim to respond
quickly to any extension needs that arise which make sense. If you
really don't agree with all this, remember that Wicket is open source.
You can always check out the source code, remove the final keyword
that offends you and rebuild the project.
Okay. I'll try to live with it. And when I find use-cases where I really
need final to be removed, I'll spam the list and either there is a
better way and I learn something, or I get my way and the final keyword
is removed. Sounds like a win-win situation! :)
Maybe this is a consequence of the fact that wicket forces you to
subclass components so much. It's just too tempting to override so much
methods. I love wicket (I really do!) but I'd rather see wicket more
event listener oriented. This would also make it easier to listen to
events that are very deeply nested (fetch the component, register a
listener), which is almost impossible now.
This is not good OO IMO. Here you break encapsulation big time. It is
much cleaner IMO to provide extension points as part of your API, not
to give full access to a component.
The following panel illustrates my point: the panel clearly publishes
two important extension points: onLogin and onLogoff. Giving direct
access to the form and having to register an onSubmitListener or the
link and having to register an onClick listener breaks encapsulation:
I am then bound to always supply the link and form. I can't make it an
ajax panel without my clients having to know about it.
public abstract class LoginPanel extends Panel {
public LoginPanel(String id) {
if(Session.get().getUser() != null) {
add(new LogoffFragment("content"));
} else {
add(new UsernamePasswordFragment("content"));
}
}
protected abstract boolean onLogin(String username, Stringpassword);
protected abstract void onLogoff();
private class LogoffFragment extends Fragment {
...
add(new Link("logoff") {
protected void onClick() {
onLogoff();
Session.get().invalidate();
}
});
...
}
Okay, I see what you mean. A component designed to do XX should publish
onXX methods that are overridable. That's so crazy it just might work!
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form.updateFormComponentModels bug?
Johan Compagner wrote: On 9/10/07, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: Hi, According to the javadoc Form.updateFormComponentModels should update all the models of all FormComponents in a form (without validation presumably?). This sets all the model objects to the convertedInput no it updates the form component models where conversion and validation did go alright. Okay, so the difference with Form.process() is that process() does not update at all when one of the FormComponents is invalid, and updateFormComponentModels updates all that ARE valid, right? So that's usually what you want (and what I want in this case). Thanks for making this clear. In Form.process() where this method is called, the form is validated first, so conversion took place as a side effect of validation. There I can see how it works. Maybe the javadoc of Form.updateFormComponentModels should state that Form.validate should be called first. Form.validate does state that: "This method is typically called before updating any models." which is good. value (in FormComponent.updateModel), unfortunately convertedInput is only set after a call to validate(). This really makes updateFormComponentModels useless as a protected method. If validation It is only protected final if you want to do some of your own processing see IFormSubmittingComponent.getDefaultFormProcessing() is really mandatory (which I doubt), processInput should be the only callable method as it validates first and then updates the model. checking required, conversion and validation is mandatory before updating models. In any case, the call to convertInput() inside validate() strikes me as odd (the wrong place to call such a method). no not really, FormComponent.validate() is really all the validation that can happen first required validation, then conversion validation and then user validation on the converted type We could split up the methods again, like in Form.process() which calls the above validate only. We could split that up in to validateRequired(), validateConversion(), validateXX() but what do we gain then? Readability! When a method is called validate() I expect it to validate, and validate ONLY. Conversion of input is a side effect of validation. Also, the javadoc of FormComponent.updateModel() states: ".. it expect that the object is already converted through the convert() call", but there is no convert() method in FormComponent. thats then an error in the doc, there are some changes in that area so that should be improved make a jira issue for this. Ehmokay. Do I really need to file a bug for this small documentation bug? Done: https://issues.apache.org/jira/browse/WICKET-951 Maybe this is a consequence of the fact that wicket forces you to subclass components so much. It's just too tempting to override so much methods. I love wicket (I really do!) but I'd rather see wicket more event listener oriented. This would also make it easier to listen to events that are very deeply nested (fetch the component, register a listener), which is almost impossible now If you want listeners like swing then that is very easy for you to make just extend link or what ever component or behavior you have once and make the add/removeXXX and fire methods on them. We have this also because it preserves memory, If you have to make an (inner)class instance and a link instance and attach those 2 each other that can consume much more memory then when just making a new class and have there one instance. I'm not sure I see what you mean, but doesn't the (inner) class also need instantiation, consuming just as much memory? Thanks for clearing some things up for me. Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Form.updateFormComponentModels bug?
Hi, According to the javadoc Form.updateFormComponentModels should update all the models of all FormComponents in a form (without validation presumably?). This sets all the model objects to the convertedInput value (in FormComponent.updateModel), unfortunately convertedInput is only set after a call to validate(). This really makes updateFormComponentModels useless as a protected method. If validation is really mandatory (which I doubt), processInput should be the only callable method as it validates first and then updates the model. In any case, the call to convertInput() inside validate() strikes me as odd (the wrong place to call such a method). Also, the javadoc of FormComponent.updateModel() states: ".. it expect that the object is already converted through the convert() call", but there is no convert() method in FormComponent. Off-topic: Why are so much methods marked final? This might prevent API-misuse but also prevents innovative _use_! I can understand you want framework users to do it the wicket way, because they will probably only spam the users list with questions that have obvious solutions (like me :D ). But sometimes it's just frustrating. Maybe this is a consequence of the fact that wicket forces you to subclass components so much. It's just too tempting to override so much methods. I love wicket (I really do!) but I'd rather see wicket more event listener oriented. This would also make it easier to listen to events that are very deeply nested (fetch the component, register a listener), which is almost impossible now. -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxFallbackButton really require Form in constructor?
Ah yes, you're right. Sorry 'bout that.
Matej Knopp wrote:
This would be wrong, as during constructor the component is not yet added to
any parent.
-Matej
On 9/3/07, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
Or maybe:
public AjaxButton(String id)
{
this(id, getForm());
}
This could work the same for AjaxFallbackButton.
Matthijs
Johan Compagner wrote:
It is needed i guess if we say that the method
protected abstract void onSubmit(AjaxRequestTarget ajaxrequesttarget,
Form
form1);
needs a form parameter that can't be null
Also i see something strange in the AjaxButton because if you dont give
the
form then the form parameter
can be null:
public AjaxButton(String id)
{
this(id, null);
}
public Form getForm()
{
if(form != null)
return form;
else
return super.getForm();
}
public AjaxButton(String id, final Form form)
{
super(id);
this.form = form;
add(new AjaxFormSubmitBehavior("onclick", form) {
protected void onSubmit(AjaxRequestTarget target)
{
AjaxButton.this.onSubmit(target, form);
}
protected void onError(AjaxRequestTarget target)
{
AjaxButton.this.onError(target, form);
}
i think this is wrong, but maybe it was on purpose?
i think it should be:
public AjaxButton(String id)
{
this(id, null);
}
public Form getForm()
{
if(form != null)
return form;
else
return super.getForm();
}
public AjaxButton(String id, final Form form)
{
super(id);
this.form = form;
add(new AjaxFormSubmitBehavior("onclick", form) {
protected void onSubmit(AjaxRequestTarget target)
{
AjaxButton.this.onSubmit(target, getForm());
}
protected void onError(AjaxRequestTarget target)
{
AjaxButton.this.onError(target, getForm());
}
So that we return the given form or try to find one.
johan
On 9/3/07, Sam Hough <[EMAIL PROTECTED]> wrote:
Since neither AjaxButton or Button require Form in the constructor why
does
AjaxFallbackButton? Seems a shame to make it required if not really
needed...
I'm not quite clear from the source or comments what the difference is
in
AjaxButton between the behaviour from the two different constructors...
--
View this message in context:
http://www.nabble.com/AjaxFallbackButton-really-require-Form-in-constructor--tf4370843.html#a12457890
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxFallbackButton really require Form in constructor?
Or maybe:
public AjaxButton(String id)
{
this(id, getForm());
}
This could work the same for AjaxFallbackButton.
Matthijs
Johan Compagner wrote:
It is needed i guess if we say that the method
protected abstract void onSubmit(AjaxRequestTarget ajaxrequesttarget, Form
form1);
needs a form parameter that can't be null
Also i see something strange in the AjaxButton because if you dont give the
form then the form parameter
can be null:
public AjaxButton(String id)
{
this(id, null);
}
public Form getForm()
{
if(form != null)
return form;
else
return super.getForm();
}
public AjaxButton(String id, final Form form)
{
super(id);
this.form = form;
add(new AjaxFormSubmitBehavior("onclick", form) {
protected void onSubmit(AjaxRequestTarget target)
{
AjaxButton.this.onSubmit(target, form);
}
protected void onError(AjaxRequestTarget target)
{
AjaxButton.this.onError(target, form);
}
i think this is wrong, but maybe it was on purpose?
i think it should be:
public AjaxButton(String id)
{
this(id, null);
}
public Form getForm()
{
if(form != null)
return form;
else
return super.getForm();
}
public AjaxButton(String id, final Form form)
{
super(id);
this.form = form;
add(new AjaxFormSubmitBehavior("onclick", form) {
protected void onSubmit(AjaxRequestTarget target)
{
AjaxButton.this.onSubmit(target, getForm());
}
protected void onError(AjaxRequestTarget target)
{
AjaxButton.this.onError(target, getForm());
}
So that we return the given form or try to find one.
johan
On 9/3/07, Sam Hough <[EMAIL PROTECTED]> wrote:
Since neither AjaxButton or Button require Form in the constructor why
does
AjaxFallbackButton? Seems a shame to make it required if not really
needed...
I'm not quite clear from the source or comments what the difference is in
AjaxButton between the behaviour from the two different constructors...
--
View this message in context:
http://www.nabble.com/AjaxFallbackButton-really-require-Form-in-constructor--tf4370843.html#a12457890
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wantOnSelectionChangedNotifications causing table redraw
Instead of using wantOnSelectionChangedNotifications you could add an
AjaxEventBehavior or AjaxFormSubmitBehavior on "onchange", depending on
whether you want the form to be processed or not.
wantOnSelectionChangedNotifications is a bit strange in that it uses
normal javascript to submit the form the formcomponent is in.
I'd rather have that onSelectionChanged would be called _any_ which way
the form was submitted, be it javascript (wantOSCN), normal submit or
ajax. Would this be the same then as onModelChanged?
Matthijs
salmas wrote:
I have a DataTable in which I have a panel which contains a textfield and a
radiogroup. When the user changes the selection in the radiogroup I'd like
to populate a value in the textfield. I subclassesed RadioGroup to catch the
selectionChangedEvent
RadioGroup choice = new RadioGroup(workflowFrame_radioPanel_radioGroup,new
Model()){
protected void onSelectionChanged(java.lang.Object newSelection) {
//Figure out what is selected and set value in textfield
}
protected boolean wantOnSelectionChangedNotifications() {
return true;
}
};
As soon as I override the wantOnSelectionChangedNotifications method I get
the notifications but the table is redrawn as soon as the user selects an
option in the radiogroup while if I do not override this method the UI does
not do this ugly redraw when the user toggles the selection in the
radiogroup. I am using AJAX to redraw my table in other instances so that
the table redraw is smooth. Is there any way I can catch the selection
changed event and have the table not redraw? I can redraw it myself with an
AJAX target after I set the value in the textfield.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IndicatingAjaxSubmitButton and download after form submission problem
Incidentally, when I woke up this morning, I was thinking about this
exact same problem :)
In the case of an Ajax button, the request is from an XmlHttpRequest
javascript (browser) object. I'm not sure if that even supports binary
results (mime types other than text/xml and text/plain), but if it does
you'd have to do something on the client side to show a download dialog
or something.
A direction to a possible solution would be to respond with some kind of
redirect to the URL of the binary (RequestCycle.urlFor(..)). Now your
only problem is how to send a redirect over the XmlHttpRequest. Your
best bet would be to send a little bit of javascript (window.location =
"[url]"), or maybe there is a component for this already.
Good luck!
Matthijs
Martin Bednář wrote:
Hi,
I have problem when I use IndicatingAjaxSubmitButton for dowload after
form submission.
I use this code, normal Button working correctly. it's bug in
IndicatingAjaxSubmitButton or I'm doing something wrong ?
...
//This dosn't work
form.add(new IndicatingAjaxSubmitButton("submit", form) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form) {
processSubmit(); }
});
//This working
form.add(new Button("submit") {
@Override
protected void onSubmit() {
processSubmit();
}
});
private void processSubmit() {
final String zipArchiveFilename = "/tmp/sample.zip";
RequestCycle requestCycle = this.getRequestCycle();
final ResourceStreamRequestTarget exportTarget = new
ResourceStreamRequestTarget(
new FileResourceStream(new wicket.util.file.File(
zipArchiveFilename)), "application/zip") {
@Override
protected void configure(Response arg0, IResourceStream arg1) {
super.configure(arg0, arg1);
WebResponse response = (WebResponse) arg0;
setFileName("sample.zip");
}
};
requestCycle.setRequestTarget(exportTarget);
}
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket vs. ZK
1. Design concern (Wicket vs. ZK) Both frameworks are thin-client and generate AJAX, the biggest difference is Wicket uses Java and HTML while ZK uses XUL or other scripting language. What's the advantage and disadvantage in both cases? Advantage of HTML is that you can work with web designers & standard tools for laying out and that you have very direct control of what will be in your users' browsers. XUL might be nice if the framework can decide to send it directly to the client if that supports it. I think XUL as a semantic UI language is great. If only more browsers would support it, we could drop HTML altogether :) I suppose one could write XUL components with wicket and have a servlet filter translate it to XHTML. The challenge would be wiring the events from the generated HTML to the wicket framework. It's an interesting idea though (I think). -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wicket:child in a WebMarkupContainer
Hi,
I have an interesting problem. I am trying to get a subclass of a
component to add it's children to a container in the superclass. This is
the markup:
SuperComponent.html
blahblahblah
blahblah
blahblahblah
SubComponent.html
my label
The problem is that when in SubComponent.java I say:
this.add(new Label("myLabel", "label text"));
the label is added to the SuperComponent instead of myContainer. This is
an error in the markup hierarchy.
The solution that first came to mind was to override add(Component) in
SuperComponent so that it would add the added component to myContainer
instead of 'this'. Unforunately, the add method is final (why!?), so
this can't be done.
The workaround is to provide a addToContainer(Component) method. I think
this is ugly because SubComponent has to have intricate knowledge of
SuperComponent and use addToContainer where it would normally use add.
SubComponent already has some knowledge of SuperComponent anyway because
it's a subclass, but still I think it's ugly.
Is there another solution to my problem? Maybe using enclosure or border
or somesuch? Any ideas?
BTW: I use wicket 1.3.0-beta2.
Regards,
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
