Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Tue, Mar 8, 2011 at 11:22 PM, Maarten Billemont lhun...@gmail.com wrote:
Just like EJBs, you should be careful about how much interaction you do
beyond your object's scope within the constructor. Your component doesn't
have a hierarchy, getPage() cannot be accessed, none of your subclass
constructors have been invoked and therefore your instance is not properly
initialized and ready for use.
not really sure what you mean by subclass constructors or how they
come into play when constructing an instance...
If I understand correctly, here is an example of what he means :
Exactly. If B extends A and I do something in A's constructor that goes
beyond the scope of setting up A's instance variables, then I risk a
side-effect that relies on the instance to be constructed at B's level as
well. There's nothing in the JVM that prevents this and these bugs are very
hard to see and debug. They should be avoided by good coding practices.
yep, calling overridable methods from constructors is bad - you just
made the case for making page.oninitialize() final...
On 08 Mar 2011, at 22:07, Igor Vaynberg wrote:
i think code like this should be possible:
NameEditor e=new NameEditor(name, firstNameModel, lastNameModel);
e.getFirstNameEditor().setRequired(true);
e.getLastNameEditor().setEnabled(false);
taking the previous example of a name editor, with constructor we have:
class nameeditor extends panel {
public nameeditor(...) {
add(new textfield(first,..);
add(new textifled(last, ...);
}
public textfield getfirst() { return get(first); }
public textfield getlast() { return get(last); }
}
Firstly, it's my opinion that you really shouldn't be doing anything to
components directly, especially not from outside your class. As for why, see
Encapsulation and Law of Demeter.
neither of the two apply because nameeditor explicitly exposes the two
components as part of its contract via public getters.
But if you really wanted to use this pattern, it really wouldn't have to be
as cumbersome as you make it out to be. Also, I really don't like condoning
get(String), it's nasty and very type-unfriendly. It also breaks as soon as
you do any refactoring in your component hierarchy.
yes, i traded off some refactorability for better memory footprint.
imho a perfectly valid trade off when memory and space are costly.
class NameEditor extends Panel {
TextFieldString firstField;
TextFieldString lastField;
@Override protected void onInitialize() { super.onInitialize();
add(getFirst(), getLast()); }
public textfield getFirst() { if (firstField == null) firstField = new
TextFieldString(); return firstField; }
public textfield getLast() { if (lastField == null) lastField = new
TextFieldString(); return lastField; }
}
there are still problems with this:
*you still have the two extra memory slots that are a complete waste
here - component references
*the lazy init code is cumbersome to write
*you are missing the two slots needed to pass models from constructor
to the two textfields - so thats four extra slots total that you have
now forced on users
* the components i get from the getters are not added to their parent
- for more complex components that need access to their markup this is
a problem, eg if
(text.equals(getFirst().getMarkupTag().get(type))...not
necessarily a good example taking this particular custom component as
context, but a valid usecase in plenty of other situations.
-igor
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
yep, calling overridable methods from constructors is bad - Yes I agree... you just made the case for making page.oninitialize() final... But isn't that the very thing that the whole overridable onInitialize method was intended to avoid as it gets called after construction by the framework. Any post construction code can simply be put in the onInitialize method. DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Wed, Mar 9, 2011 at 12:22 AM, Coleman, Chris chris.cole...@thalesgroup.com.au wrote: yep, calling overridable methods from constructors is bad - Yes I agree... you just made the case for making page.oninitialize() final... But isn't that the very thing that the whole overridable onInitialize method was intended to avoid as it gets called after construction by the framework. Any post construction code can simply be put in the onInitialize method. the way the code is implemented page's oninitialize() would get called on first page#add() invocation and since the add() invocation is most likely inside page's constructor... -igor DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
yep, calling overridable methods from constructors is bad - you just made the case for making page.oninitialize() final... No, I've made the case for this issue. Either add() should be disallowed from the constructor (meaning onInitialize won't get called from it), onInitialize should be made final (meaning onInitialize will do nothing when it gets called), or Page should stop calling initialize() as a result of a component being added, and behave like any other component does. Would you mind addressing this third option? What exactly is the reason for Page behaving in this special way? On 09 Mar 2011, at 09:15, Igor Vaynberg wrote: Firstly, it's my opinion that you really shouldn't be doing anything to components directly, especially not from outside your class. As for why, see Encapsulation and Law of Demeter. neither of the two apply because nameeditor explicitly exposes the two components as part of its contract via public getters. Allow me to remind you: More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects: • O itself • M's parameters • any objects created/instantiated within M • O's direct component objects • a global variable, accessible by O, in the scope of M Making your components available via getters does not excuse anything. The list does not include invoke methods on any objects created by any objects created within M, for good reason. Also, I really don't like condoning get(String), it's nasty and very type-unfriendly. It also breaks as soon as you do any refactoring in your component hierarchy. yes, i traded off some refactorability for better memory footprint. imho a perfectly valid trade off when memory and space are costly. there are still problems with this: *you still have the two extra memory slots that are a complete waste here - component references You're talking about the cost of a reference to a component. It's not like you've got a COPY of the component in your field. And no, it's not a good trade-off. You're writing Java applications, you'll be deploying in Java application containers, you're working with a web framework that goes to great lengths to help the container provide solid clustering. Your memory footprint is absolutely subordinate to decently maintainable and compile-time checked code. If you're a developer that doesn't appreciate the latter, you'll find that you can be a lot more flexible using a language with weak type checking, at the cost of maintainable code. Any Java developer should not be willing to make this trade-off, especially when it's as light as this one. Your component gets added to your page anyway! *the lazy init code is cumbersome to write Hardly, but you shouldn't be doing it anyway except for special cases where you can forgive yourself the bad design. *you are missing the two slots needed to pass models from constructor to the two textfields - so thats four extra slots total that you have now forced on users You really shouldn't be having references to your components and have only two slots for your models, but if you want to provide getters for your components, yes, you need instance fields for them. Because get(String) is nasty. This really doesn't have anything to do with the difference between constructor and onInitialize initialization, except for the added bonus that you can't do nasty get(String) in the latter case before your component is initialized. The second option is looking better and better to me. * the components i get from the getters are not added to their parent - for more complex components that need access to their markup this is a problem, eg if (text.equals(getFirst().getMarkupTag().get(type))...not necessarily a good example taking this particular custom component as context, but a valid usecase in plenty of other situations. Irrelevant, even if you added them in your constructor, you don't have access to your markup before you add your newly created NameEditor to a page hierarchy. This example does help to confirm the need for an onInitialize: Don't touch your components until onInitialize is called indicating that the page hierarchy and markup are available. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 3/8/11 12:33 PM, Martijn Dashorst wrote:
On Tue, Mar 8, 2011 at 6:03 PM, GOODWIN, MATTHEW (ATTCORP)
mg0...@att.com wrote:
+1 for clear documentation/Javadoc explaining proper use of
onInitialize.
Does this exist somewhere? As someone new to Wicket I'm trying to learn
as fast as I can and a lot of examples (almost exclusively) I see out
there show the add(..) from within the constructor - which is apparently
an anti-pattern from the sound of this thread.
It is most certainly not an antipattern in my book. I find the
reaction of the anti-constructor folks too strong and am trying to
formulate a civil reaction to this whole anti constructor rant.
Martijn
*Please* don't deprecate add() from constructor.
While a minority use-case, this allows for very elegant Wicket code when
using Scala:
add(new Form[Person](form, model) {
add (new TextArea[String](text, (getModel - text)) {
override def isVisible: Boolean = false
})
})
etc.
Since the body of a class is the constructor in Scala, this is a perfect
fit for closure-like structures when using Wicket.
Thanks,
Gary
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 10:44, Gary Thomas wrote:
While a minority use-case, this allows for very elegant Wicket code when
using Scala:
add(new Form[Person](form, model) {
add (new TextArea[String](text, (getModel - text)) {
override def isVisible: Boolean = false
})
})
Style is great when there are no issues involved with doing it. If it turns
out that adding components from the constructor is indeed dangerous when
combined with other components (eg. in libraries) that use onInitialize then we
should reconsider.
I think the best solution so far would be to not invoke onInitialize when
adding components to a page, that would allow the constructor to be used still
if the developer really wants to.
With regards to your Scala code, while I don't know any Scala whatsoever,
wouldn't it be just as easy to do something like this:
add(new Form[Person](form, model) {
override def onInitialize: add (new TextArea[String](text, (getModel -
text)) {
override def isVisible: Boolean = false
})
})
Which would give you the added lazy component construction bonus that
onInitialize provides, as well as your elegance.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Disabled Field
Hi, I have done the following to disabled the text field. field.setDisabled(isDisabled); now when I inspect the html code in the browser the *value* attribute is missing. Can you suggest me a solution for this. _Hiren a href= http://kaleusermeet-march-2011.doattend.com/; img src= http://email.kaleconsultants.com/imgs/kale2.jpg;/ap Disclaimer: This email (including any attachments) is intended for the sole use of the recipient/s and may contain material that is CONFIDENTIAL. Any unauthorized disclosure / copying / distribution or forwarding of this message or part is STRICTLY PROHIBITED. If you have erroneously received this message, please delete it immediately and notify the sender. No liability is assumed for any errors and/or omissions in the contents of this message. Information in this message that does not relate to the official business of this Company shall be understood as neither given nor endorsed by it. If verification is required please request a hard-copy version. To know more about Kale Consultants, visit www.kaleconsultants.com -=-=-=-=-=-=-=-=-=-
Externalizing Page Mounts Via Spring
Hi,
I wanted to externalize the Page Mounts using Spring.
Earlier in my Application class the code was like:
mount(new QueryStringUrlCodingStrategy(login, loginPage.class));
So What I did was:
...
//Scan for All IMountLoaders in the context and get the
Mount points from them automatically
Map mountLoadersMap =
springContext.getBeansOfType(IMountLoader.class);
List mountPoints = ... Get Mount Points from Spring ...
for (IRequestTargetUrlCodingStrategy mountPoint : mountPoints) {
mount(mountPoint);
}
...
: SPRING FILE CORRESPONDING CONFIG :
However this leads to an Exception:
.springframework.beans.BeanInstantiationException: Could not instantiate
bean class [com.me.loginPage]: Constructor threw exception; nested exception
is java.lang.IllegalStateException: you can only locate or create sessions
in the context of a request cycle:
java.lang.IllegalStateException: you can only locate or create sessions in
the context of a request cycle
at org.apache.wicket.Session.findOrCreate(Session.java:209)
at org.apache.wicket.Session.get(Session.java:253)
at
org.apache.wicket.Application$1.onInstantiation(Application.java:299)
at
org.apache.wicket.Application.notifyComponentInstantiationListeners(Application.java:1093)
I wanna keep the code fluid and dont wanna wire it to any specific
@SpringBean kinda config. Is there an easy way out here?
-
Don't take life too seriously, your'e not getting out it alive anyway!
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Externalizing-Page-Mounts-Via-Spring-tp3343247p3343247.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Externalizing Page Mounts Via Spring
Your xml config tries to instantiate the page. Try this:
bean
class=org.apache.wicket.request.target.coding.QueryStringUrlCodingStrategyconstructor-arg
index=0 value=login /constructor-arg index=1
value=com.me.loginPage //bean
Attila
2011/3/9 Arjun Dhar dhar...@yahoo.com
Hi,
I wanted to externalize the Page Mounts using Spring.
Earlier in my Application class the code was like:
mount(new QueryStringUrlCodingStrategy(login, loginPage.class));
So What I did was:
...
//Scan for All IMountLoaders in the context and get the
Mount points from them automatically
Map mountLoadersMap =
springContext.getBeansOfType(IMountLoader.class);
List mountPoints = ... Get Mount Points from Spring ...
for (IRequestTargetUrlCodingStrategy mountPoint :
mountPoints) {
mount(mountPoint);
}
...
: SPRING FILE CORRESPONDING CONFIG
:
However this leads to an Exception:
.springframework.beans.BeanInstantiationException: Could not instantiate
bean class [com.me.loginPage]: Constructor threw exception; nested
exception
is java.lang.IllegalStateException: you can only locate or create sessions
in the context of a request cycle:
java.lang.IllegalStateException: you can only locate or create sessions in
the context of a request cycle
at org.apache.wicket.Session.findOrCreate(Session.java:209)
at org.apache.wicket.Session.get(Session.java:253)
at
org.apache.wicket.Application$1.onInstantiation(Application.java:299)
at
org.apache.wicket.Application.notifyComponentInstantiationListeners(Application.java:1093)
I wanna keep the code fluid and dont wanna wire it to any specific
@SpringBean kinda config. Is there an easy way out here?
-
Don't take life too seriously, your'e not getting out it alive anyway!
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Externalizing-Page-Mounts-Via-Spring-tp3343247p3343247.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Using jQuery with Wicket
I have some html pages including some jquery functionaliy. For example: select a choice from a select box then click a button moves this choice to the other select box but what i need to do is also update the select box (list)content also. How can I do that? Any suggestions? With my best regards. - Developer Wicket Java JSP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Using-jQuery-with-Wicket-tp3343275p3343275.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
how to process radioButtons
Dear All
I have a list of user names, I populated listView using it, with each
username I created three radion buttons (present,absent, leave), please see
appended source code
I want when I click save button then status of each username printed or
saved, how to do it.
*
ListView* listView = *new ListView(profile-rows, UserNameList)//id, list
{
protected void populateItem(ListItem item) //foreach item in data
{
NameWrapper person = (NameWrapper) item.getModelObject();
item.add(new Label(first-name, person.getName()));
final RadioGroup statusRadioGroup = new RadioGroup(radio-admin, newModel());
item.add(statusRadioGroup );
statusRadioGroup .add(new Radio(present, new Model()));
statusRadioGroup .add(new Radio(absent, new Model()));
statusRadioGroup .add(new Radio(leave, new Model()));
}
}*;
profileForm.add(listView);
profileForm.add(*new* Button(button-save, *new Model()*));
add(profileForm);
Re: Externalizing Page Mounts Via Spring
Am 09.03.2011 11:28, schrieb Arjun Dhar:
Hi,
I wanted to externalize the Page Mounts using Spring.
Earlier in my Application class the code was like:
mount(new QueryStringUrlCodingStrategy(login, loginPage.class));
So What I did was:
...
//Scan for All IMountLoaders in the context and get the
Mount points from them automatically
Map mountLoadersMap =
springContext.getBeansOfType(IMountLoader.class);
List mountPoints = ... Get Mount Points from Spring ...
for (IRequestTargetUrlCodingStrategy mountPoint : mountPoints) {
mount(mountPoint);
}
...
: SPRING FILE CORRESPONDING CONFIG :
However this leads to an Exception:
.springframework.beans.BeanInstantiationException: Could not instantiate
bean class [com.me.loginPage]: Constructor threw exception; nested exception
is java.lang.IllegalStateException: you can only locate or create sessions
in the context of a request cycle:
java.lang.IllegalStateException: you can only locate or create sessions in
the context of a request cycle
at org.apache.wicket.Session.findOrCreate(Session.java:209)
at org.apache.wicket.Session.get(Session.java:253)
at
org.apache.wicket.Application$1.onInstantiation(Application.java:299)
at
org.apache.wicket.Application.notifyComponentInstantiationListeners(Application.java:1093)
I wanna keep the code fluid and dont wanna wire it to any specific
@SpringBean kinda config. Is there an easy way out here?
-
Don't take life too seriously, your'e not getting out it alive anyway!
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Externalizing-Page-Mounts-Via-Spring-tp3343247p3343247.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
There is a realy cool annotation project in wicket-stuff. With this you
could externalize the packages to scan for pages. Mounting goes to page
and scanned packages to spring-config.
Doc:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-annotation
Just my 2$.
Mike
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Externalizing Page Mounts Via Spring
Both very helpful answers @Mike ManderThe wicket-stuff thing is very cool indeed. However, I'd like to mounting to be controlled by some strategy/configuration in most cases which wont help if i have the Annotation within the WebPage (but yes very very cool to know it exists). @Attila Király : Yah worked, though one doesnt need index values since they are in order; but using the String value instead of the object did the trick! thank you - Don't take life too seriously, your'e not getting out it alive anyway! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Externalizing-Page-Mounts-Via-Spring-tp3343247p3343358.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using jQuery with Wicket
Hi tech7, could Palette component be helpfull for you? http://wicketstuff.org/wicket14/compref/?wicket:bookmarkablePage=:org.apache.wicket.examples.compref.PalettePage I have some html pages including some jquery functionaliy. For example: select a choice from a select box then click a button moves this choice to the other select box but what i need to do is also update the select box (list)content also. How can I do that? Any suggestions? With my best regards. - Developer Wicket Java JSP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Using-jQuery-with-Wicket-tp3343275p3343275.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using jQuery with Wicket
Thank you for your response. Actually this is not meet with my requirements. Any other suggestion? - Developer Wicket Java JSP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Using-jQuery-with-Wicket-tp3343275p3343437.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Storing ArrayList with over 10000 objects
I have One Array-list(with over 1 objects in it) what is the best practice for caching it so I don't have to load it over and over again in each request? Jan
Re: Storing ArrayList with over 10000 objects
On Wed, Mar 9, 2011 at 1:00 PM, Jan Juno janko...@gmail.com wrote: I have One Array-list(with over 1 objects in it) what is the best practice for caching it so I don't have to load it over and over again in each request? Usually at our company we expect our ORM mapper (hibernate) to take care of caching, so it is not a problem for us to ask the ORM for the same query again and again and again. I'd use a cache for that. Either something home grown (usually not a great idea, but for a single use case it might work), or something like ehcache. If the item can't be found in the cache, retrieve it from data store and put it in cache. I wouldn't keep the 10k objects in a page instance or the user session since that will be serialized with each request. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Storing ArrayList with over 10000 objects
can you point me to a good wicket + ehcache tutorial? On 9 March 2011 13:13, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Wed, Mar 9, 2011 at 1:00 PM, Jan Juno janko...@gmail.com wrote: I have One Array-list(with over 1 objects in it) what is the best practice for caching it so I don't have to load it over and over again in each request? Usually at our company we expect our ORM mapper (hibernate) to take care of caching, so it is not a problem for us to ask the ORM for the same query again and again and again. I'd use a cache for that. Either something home grown (usually not a great idea, but for a single use case it might work), or something like ehcache. If the item can't be found in the cache, retrieve it from data store and put it in cache. I wouldn't keep the 10k objects in a page instance or the user session since that will be serialized with each request. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using jQuery with Wicket
on the first Select , and an ajax form compenent behavior for 'onchange' , On the implementation , remove the item from the first select's model, add it to the other select component's model then add both select components to the target. Also use LoadableDetachableModels for your select components so that their contents is 'recalculated' a fresh when its rendered. Am assuming you know about models and Ajax behaviours. Josh.
Re: Storing ArrayList with over 10000 objects
Martijn,
Wouldn't this be a safe way to cache a list at the expense of memory (using
transient)? In a lot of my projects I have to do some aggregation of the
results from multiple data stores that are slow even with the caching layer.
private class SomeDataProvider extends SortableDataProvider {
/* cache the page results but don't serialize them to session
or disk */
private transient SearchResults searchResults;
private static final long serialVersionUID = 1L;
private SortParam sortParam;
public SomeDataProvider () {}
@Override
public int size() {
/*
* if null (back button/forward button case) rebuild
the results using
the search parmas that are stored with page
*/
if (searchResults == null) {
searchResults =
searchService.findSomeStuff(serializableSearchParams);
}
return searchResults.size();;
}
@Override
public IModel model(Object object) {
return new
SearchHitModel(object).setShouldDetach(false);
}
@Override
public Iterator iterator(int first, int count) {
SortParam sp = getSort();
// only sort results when the sort command changes
if (!sortParam.equals(sp)) {
Sorter sorter = new Sorter(sp.getProperty(),
sp.isAscending());
Collections.sort(searchResults.getSearchResultList(), sorter);
sortParam = sp;
}
return searchResults.getPagedResults(first,
count).iterator();
}
}
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Storing-ArrayList-with-over-1-objects-tp3343442p3343499.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Before deployment checklist
Hello. I am getting close to deploying my first wicket web application. It's not huge but it does have lots of classes, components, database stuff, search features, etc. I was wondering if anyone had some kind of checklist on what things to definitely check before deploying a wicket application into production. Thanks. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Before deployment checklist
Hi!
Is a good idea to have appropriate build script that does the changes
/ assert checklist for you.
For example,
target name=replace depends=copy description=o Test
replace file=${targetspace}\src\webapp\WEB-INF\web.xml
replacetoken![CDATA[param-valuedevelopment/param-value]]/replacetoken
replacevalue![CDATA[param-valuedeployment/param-value]]/replacevalue
/replace
replace file=${targetspace}\src\main\java\META-INF\persistence.xml
replacetoken![CDATA[property name=hibernate.dialect
value=org.hibernate.dialect.MySQL5InnoDBDialect/]]/replacetoken
replacevalue![CDATA[property name=hibernate.dialect
value=org.hibernate.dialect.PostgreSQLDialect/]]/replacevalue
/replace
replace file=${targetspace}\src\main\java\META-INF\persistence.xml
replacetoken![CDATA[property
name=hibernate.connection.url
value=jdbc:mysql://localhost:3306/takp/]]/replacetoken
replacevalue![CDATA[property
name=hibernate.connection.url
value=jdbc:postgresql://localhost:5432/takp/]]/replacevalue
/replace
replace file=${targetspace}\src\main\java\META-INF\persistence.xml
replacetoken![CDATA[property
name=hibernate.connection.driver_class
value=com.mysql.jdbc.Driver/]]/replacetoken
replacevalue![CDATA[property
name=hibernate.connection.driver_class
value=org.postgresql.Driver/]]/replacevalue
fail message=Wrong configuration
condition
or
not
resourcecount count=1
fileset
file=${targetspace}\src\main\java\META-INF\persistence.xml
contains text='property name=hibernate.hbm2ddl.auto
value=false' casesensitive=yes/
/fileset
/resourcecount
/not
not
resourcecount count=1
fileset
file=${targetspace}\src\main\java\META-INF\persistence.xml
contains text='property name=hibernate.show_sql
value=false' casesensitive=yes/
/fileset
/resourcecount
/not
not
**
Martin
2011/3/9 Henrique Boregio hbore...@gmail.com:
Hello. I am getting close to deploying my first wicket web
application. It's not huge but it does have lots of classes,
components, database stuff, search features, etc.
I was wondering if anyone had some kind of checklist on what things to
definitely check before deploying a wicket application into
production.
Thanks.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Storing ArrayList with over 10000 objects
Should work, though perhaps going to the datastore for each
back/forward button press might be overkill. Retrieving it from a
cache, like ehcache, allows you to set an expiry on the data, keep it
thread safe and even memory safe (i.e. let ehcache throw away the
objects when memory is tight, or let it write to disk if not used for
a while).
AFAIK there are no examples on the web utilizing ehcache and wicket
specifically. Just use a plain ehcache example, and access the cache
store in a loadable detacheble model, or possibly even in your service
method.
Martijn
On Wed, Mar 9, 2011 at 1:48 PM, robert.mcguinness
robert.mcguinness@gmail.com wrote:
Martijn,
Wouldn't this be a safe way to cache a list at the expense of memory (using
transient)? In a lot of my projects I have to do some aggregation of the
results from multiple data stores that are slow even with the caching layer.
private class SomeDataProvider extends SortableDataProvider {
/* cache the page results but don't serialize them to session
or disk */
private transient SearchResults searchResults;
private static final long serialVersionUID = 1L;
private SortParam sortParam;
public SomeDataProvider () {}
@Override
public int size() {
/*
* if null (back button/forward button case) rebuild
the results using
the search parmas that are stored with page
*/
if (searchResults == null) {
searchResults =
searchService.findSomeStuff(serializableSearchParams);
}
return searchResults.size();;
}
@Override
public IModel model(Object object) {
return new
SearchHitModel(object).setShouldDetach(false);
}
@Override
public Iterator iterator(int first, int count) {
SortParam sp = getSort();
// only sort results when the sort command changes
if (!sortParam.equals(sp)) {
Sorter sorter = new Sorter(sp.getProperty(),
sp.isAscending());
Collections.sort(searchResults.getSearchResultList(), sorter);
sortParam = sp;
}
return searchResults.getPagedResults(first,
count).iterator();
}
}
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Storing-ArrayList-with-over-1-objects-tp3343442p3343499.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Storing ArrayList with over 10000 objects
Hi, Another way is to have a service manage the list. We have a reference data list (list of streets) in our application that has 100k elements that is stored in memory and we have a service hold one instance that is shared between all accessors (typically the autocomplete search fields) of the data. The list is built when the application starts up and has defined refresh points and then all users can just access the data through the service. e.g. public ListStreetData referenceDataService.find(String streetNamePrefix); Since we use spring and inject the service using @SpringBean it is wrapped in a proxy that prevents the 100k element list from being serialized with the page. Regards, Mike I have One Array-list(with over 1 objects in it) what is the best practice for caching it so I don't have to load it over and over again in each request? Jan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using jQuery with Wicket
Josh thank you for response.I will do that. Also I have another question: I have a page extending from basepage and i have i second page also extending from base page. When I click on submit button on first page it will redirect me to second page but it gives an error like that: WicketMessage: Property 'label.date' not found in property files. Markup: [markup = file:/D:/usr/glassfish2.1/domains/domain1/applications/j2ee-mo. and also at the below part of the error page it also gives an error like that: , index = 15, current = [Raw markup]] at org.apache.wicket.markup.resolver.WicketMessageResolver$MessageContainer.onComponentTagBody(WicketMessageResolver.java:217) at org.apache.wicket.Component.renderComponent(Component.java:2680) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1538) at org.apache.wicket.Component.render(Component.java:2511) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229) at org.apache.wicket.markup.resolver.WicketMessageResolver.resolve(WicketMessageResolver.java:148) at org.apache.wicket.markup.resolver.ComponentResolvers.resolve(ComponentResolvers.java:81) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1444) at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1603) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1527) at org.apache.wicket.Component.renderComponent(Component.java:2680) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1538) at org.apache.wicket.Component.render(Component.java:2511) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229) at org.apache.wicket.markup.resolver.MarkupInheritanceResolver.resolve(MarkupInheritanceResolver.java:66) at org.apache.wicket.markup.resolver.ComponentResolvers.resolve(ComponentResolvers.java:81) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1444) at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1603) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1527) at org.apache.wicket.Component.renderComponent(Component.java:2680) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1538) at org.apache.wicket.Component.render(Component.java:2511) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229) at org.apache.wicket.markup.resolver.MarkupInheritanceResolver.resolve(MarkupInheritanceResolver.java:73) at org.apache.wicket.markup.resolver.ComponentResolvers.resolve(ComponentResolvers.java:81) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1444) at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1554) at org.apache.wicket.Page.onRender(Page.java:1594) at org.apache.wicket.Component.render(Component.java:2511) at org.apache.wicket.Page.renderPage(Page.java:932) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:261) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:105) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1258) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:319) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:313) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
Re: Using jQuery with Wicket
any idea? I am really stuck with that. I will be thankful if you share your idea with me. - Developer Wicket Java JSP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Using-jQuery-with-Wicket-tp3343275p3344002.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Disabled Field
On Wed, Mar 9, 2011 at 12:25 PM, Hiren Patel hiren_pa...@kaleconsultants.com wrote: Hi, I have done the following to disabled the text field. field.setDisabled(isDisabled); There is no method setDisabled() in Wicket. now when I inspect the html code in the browser the *value* attribute is missing. Can you suggest me a solution for this. We need more info to be able to help you. _Hiren a href= http://kaleusermeet-march-2011.doattend.com/; img src= http://email.kaleconsultants.com/imgs/kale2.jpg;/ap Disclaimer: This email (including any attachments) is intended for the sole use of the recipient/s and may contain material that is CONFIDENTIAL. Any unauthorized disclosure / copying / distribution or forwarding of this message or part is STRICTLY PROHIBITED. If you have erroneously received this message, please delete it immediately and notify the sender. No liability is assumed for any errors and/or omissions in the contents of this message. Information in this message that does not relate to the official business of this Company shall be understood as neither given nor endorsed by it. If verification is required please request a hard-copy version. To know more about Kale Consultants, visit www.kaleconsultants.com -=-=-=-=-=-=-=-=-=- -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: Using jQuery with Wicket
Hi, how do you add this label to your page? can you show initialization code of second page? any idea? I am really stuck with that. I will be thankful if you share your idea with me. - Developer Wicket Java JSP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Using-jQuery-with-Wicket-tp3343275p3344002.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using jQuery with Wicket
Hi, I am calling second page onsubmit method of the first page as: setResponsePage(PGSecond.class); and on the second page label is added as: Thanx. - Developer Wicket Java JSP -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Using-jQuery-with-Wicket-tp3343275p3344131.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Wed, Mar 9, 2011 at 1:15 AM, Maarten Billemont lhun...@gmail.com wrote:
yep, calling overridable methods from constructors is bad - you just
made the case for making page.oninitialize() final...
No, I've made the case for this issue. Either add() should be disallowed
from the constructor (meaning onInitialize won't get called from it),
onInitialize should be made final (meaning onInitialize will do nothing when
it gets called), or Page should stop calling initialize() as a result of a
component being added, and behave like any other component does. Would you
mind addressing this third option? What exactly is the reason for Page
behaving in this special way?
page.add() is where the oninitialize cascade is initiated because that
is the earliest point at which the page instance is known. doing it
from there ensures that the page is more or less fully constructed
after it is instantiated allowing you to call methods on it.
eg MyPage page=new MyPage();
page.foo() { where foo manipulates state of page's child components }
i know that is not the style you prefer to use in your applications,
but that doesnt mean no one should be able to use it.
On 09 Mar 2011, at 09:15, Igor Vaynberg wrote:
Firstly, it's my opinion that you really shouldn't be doing anything to
components directly, especially not from outside your class. As for why,
see Encapsulation and Law of Demeter.
neither of the two apply because nameeditor explicitly exposes the two
components as part of its contract via public getters.
Allow me to remind you:
More formally, the Law of Demeter for functions requires that a method M of
an object O may only invoke the methods of the following kinds of objects:
• O itself
• M's parameters
• any objects created/instantiated within M
• O's direct component objects
• a global variable, accessible by O, in the scope of M
Making your components available via getters does not excuse anything. The
list does not include invoke methods on any objects created by any objects
created within M, for good reason.
yes, and if we follow this good reason then i would have to add the
following methods:
nameditor {
setfirstnamevisible() {}
setlastnamevisible() {}
setfirstnameenabled() {}
setlastnameenabled() {}
setfirstnamerequired() {}
setlastnamerequired() {}
addfirstnamevalidator() {}
addlastnamevalidator() {}
setfirstnamelabel() {}
setlastnamelabel() {}
}
just to name a few, and all they do is forward stuff to the two inner
components. sounds like a lot of fun...
Also, I really don't like condoning get(String), it's nasty and very
type-unfriendly. It also breaks as soon as you do any refactoring in your
component hierarchy.
yes, i traded off some refactorability for better memory footprint.
imho a perfectly valid trade off when memory and space are costly.
there are still problems with this:
*you still have the two extra memory slots that are a complete waste
here - component references
You're talking about the cost of a reference to a component. It's not like
you've got a COPY of the component in your field. And no, it's not a good
trade-off. You're writing Java applications, you'll be deploying in Java
application containers, you're working with a web framework that goes to
great lengths to help the container provide solid clustering. Your memory
footprint is absolutely subordinate to decently maintainable and compile-time
checked code. If you're a developer that doesn't appreciate the latter,
you'll find that you can be a lot more flexible using a language with weak
type checking, at the cost of maintainable code. Any Java developer should
not be willing to make this trade-off, especially when it's as light as this
one. Your component gets added to your page anyway!
in a perfect world where your servers have unlimited amounts of memory
and your cluster's backplane is infinitely fast that would be true.
apparently youve missed some recent threads on this list about people
trying to optimize state. when you have a table with 100-200 rows and
each row has 2-3 instances of such editors, all of a sudden those two
extra slots add up.
if you dont need to optimize your state thats great, but we should
leave the door open for when you do.
*the lazy init code is cumbersome to write
Hardly, but you shouldn't be doing it anyway except for special cases where
you can forgive yourself the bad design.
well, in that case you shouldnt mind writing code like this:
class mypage extends page {
private boolean initialized=false;
protected void onconfigure() { if (!initialized) {
initialized=true; myOneTimeInitializationCode(); }}
}
*you are missing the two slots needed to pass models from constructor
to the two textfields - so thats four extra slots total that you have
now forced on users
You really shouldn't be having references to your components and have only
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
I have a c++ background and this kind of problem is even more dangerous in c++ (virtual calls don't work as normal in constructors). In Java also, I think making this known to the outside world before it is fully constructed is unsafe, as illustrated above. It's a potential problem we've been aware of and consciously allowed to exist in Wicket for a long time after our failed attempt to address it on Wicket 2.0 (years ago). In the end I don't think it is a concrete very often, and the difficulties that get introduced trying to fix it are simply not worth it in our case. Eelco - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 3/9/11 2:18 AM, Maarten Billemont wrote:
On 09 Mar 2011, at 10:44, Gary Thomas wrote:
While a minority use-case, this allows for very elegant Wicket code when using
Scala:
add(new Form[Person](form, model) {
add (new TextArea[String](text, (getModel - text)) {
override def isVisible: Boolean = false
})
})
Style is great when there are no issues involved with doing it. If it turns
out that adding components from the constructor is indeed dangerous when
combined with other components (eg. in libraries) that use onInitialize then we
should reconsider.
I think the best solution so far would be to not invoke onInitialize when
adding components to a page, that would allow the constructor to be used still
if the developer really wants to.
With regards to your Scala code, while I don't know any Scala whatsoever,
wouldn't it be just as easy to do something like this:
add(new Form[Person](form, model) {
override def onInitialize: add (new TextArea[String](text, (getModel -
text)) {
override def isVisible: Boolean = false
})
})
Thanks for the reply -
Yes it would be as simple as that - but again, not quite as elegant (imho).
I admit my argument is pretty minor, but elegant code is a hallmark of
an API or library that is designed well, and I think Wicket is great in
that regard.
Scala aside, the current usage of add() from the constructor just makes
sense to me, since you really are constructing the component. Fully
understood there are valid concerns about the side effects of this
design, but would love to see that resolved transparently if at all
possible.
I'm not an expert on the internals, but am a very happy user of Wicket :-)
Thanks,
Gary
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Wizard Step iComplete and Validation
Hi everyone, In a quite complex wizard Wicket based application, I have filled a WizardModel with many steps. Each of those steps required some mandatories inputs, which are validated against Wicket IValidator mechanism. The overview component of the Wizard is implemented with a custom WizardNavigator which list the wizard steps with their complete attribute (checkbox). Would it be possible to map the isComplete attribute of one Step with the wicket validation engine result ? Thanks a lot for your answer and for the great piece of code Wicket is ! R -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Wizard-Step-iComplete-and-Validation-tp3344208p3344208.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: preferred php framework by wicketeers...
On Tue, Mar 8, 2011 at 3:34 PM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: On Tue, Mar 8, 2011 at 1:21 PM, Antoine van Wel antoine.van@gmail.com wrote: Since you can't always have what you want.. Is there any PHP framework out there which comes even close to Wicket; component based, strict separation between HTML and programming, stateful, out-of-the-box Ajax support, event handling, URL mapping, excellent testing features, and great community support? it would probably have turned up in your google search if it existed ;-) A prototype is easy to make though; you should get a lot of benefits already from adopting the wicket session mgmt, component rendering model to php. In fact, I built something like this for fun some time ago. No ajax, url mapping, models, other fancy stuff. But event handling and markup/code separation is pretty easy to accomplish. You'ld probably want to use smarty for the rendering though. It doesn't make a lot of sense to parse html on each request and smarty probably has the best tooling for php templating. cheers, Frank Thanks all for your answers and ideas. Let me summarize by: nothing comes close to Wicket in the PHP world, except for some individual features. Perhaps in other languages there's something better, but not in PHP. Excellent :) Antoine - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
alert error message for a missing javascript resource?
wicket 1.4.9
When a wicket behavior tries to load a javascript resource from the response, I
want to create some error handler (a javascript alert) that runs if the
javascript package resource is not found.
I set an IAjaxCallDecorator which spits out a javascript string on failure, but
the failure decoration isn't being used in the case where the script resource
returns a 404. My link:
return new AjaxFallbackLink(linkId) {
protected IAjaxCallDecorator getAjaxCallDecorator() {
CompositeAjaxCallDecorator decorator = new
CompositeAjaxCallDecorator();
decorator.setFailureDecorator(new
SimpleScriptDecorator(
alert('An error occurred
communicating with the server. Please contact a system administrator.');));
return decorator;
}
...
};
I can see that my CompositeAjaxCallDecorator generates the event handler
correctly in the output, so I'm not going to post the code for that class. The
output:
a onclick=var
wcall=wicketAjaxGet('../?wicket:interface=:6:contentPanel:tabPanel:tabs-container:tabs:1:link::IBehaviorListener:0:1',function()
{ }.bind(this),function() {
alert('An error occurred communicating with the server. Please contact an AIMS
administrator.');}.bind(this), function() {return Wicket.$('link49c') !=
null;}.bind(this));return !wcall; id=link49c
href=../?wicket:interface=:6:contentPanel:tabPanel:tabs-container:tabs:1:link::ILinkListener::spanImport/span/a
When I click on the link, the wicket ajax debug shows:
INFO: Initiating Ajax GET request on
../resources/com.csc.aims.wicket.behaviors.calldecorator.ClearFeedbackScriptDecorator/ClearFeedbackScriptDecorator.js
INFO: Invoking pre-call handler(s)...
INFO: focus removed from link49c
ERROR: Received Ajax response with code: 404
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
INFO: focus set on link49c
INFO: focus removed from link49c
I did some debugging, and noticed that in wicket-ajax.js, the script element is
loaded from the response using a second ajax request:
1613// we need to schedule the request as timeout
1614// calling xml http request from another request call stack doesn't work
1615window.setTimeout(function() {
1616 var req = new Wicket.Ajax.Request(src, onLoad, false, false);
1617 req.debugContent = false;
1618 if (Wicket.Browser.isKHTML())
1619 // konqueror can't process the ajax response
asynchronously, therefore the
1620 // javascript loading must be also synchronous
1621 req.async = false;
1622 // get the javascript
1623 req.get();
1624},1);
This second ajax request doesn't specify a failure handler, so I'm thinking
that he's the culprit.
How can I fix this?
Thanks,
RUSSELL E. MORRISEY
Programmer Analyst Professional
Mission Solutions Engineering, LLC
| russell.morri...@missionse.com | www.missionse.comhttp://www.missionse.com/
304 West Route 38, Moorestown, NJ 08057-3212
This is a PRIVATE message. If you are not the intended recipient, please delete
without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind MSE to any
order or other contract unless pursuant to explicit written agreement or
government initiative expressly permitting the use of e-mail for such purpose.
Re: CompoundPropertyModel deprecated in 1.5 - what is the replacement?
On Wed, Mar 9, 2011 at 9:56 AM, Coleman, Chris chris.cole...@thalesgroup.com.au wrote: I noticed that CompoundPropertyModel is deprecated in 1.5 but I can't find anything relating to this on the Migration to Wicket 1.5 page. What is meant to be used instead of this class? It is not deprecated. DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: Models doco page typo?
Wicket 2 has been discontinued. Most of the features in it has been merged to 1.4/1.5. Some of them was considered unsuccessful and dropped. On Wed, Mar 9, 2011 at 9:46 AM, Coleman, Chris chris.cole...@thalesgroup.com.au wrote: At the bottom of this page: https://cwiki.apache.org/WICKET/working-with-wicket-models.html it says that the IModel interface was simplified in Wicket 2.0... should that really be Wicket 1.2? Never heard of Wicket 2 and I can see the 'new' style interface in Javadocs for 1.5. DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 19:15, Gary Thomas wrote:
On 3/9/11 2:18 AM, Maarten Billemont wrote:
On 09 Mar 2011, at 10:44, Gary Thomas wrote:
While a minority use-case, this allows for very elegant Wicket code when
using Scala:
add(new Form[Person](form, model) {
add (new TextArea[String](text, (getModel - text)) {
override def isVisible: Boolean = false
})
})
Style is great when there are no issues involved with doing it. If it turns
out that adding components from the constructor is indeed dangerous when
combined with other components (eg. in libraries) that use onInitialize then
we should reconsider.
I think the best solution so far would be to not invoke onInitialize when
adding components to a page, that would allow the constructor to be used
still if the developer really wants to.
With regards to your Scala code, while I don't know any Scala whatsoever,
wouldn't it be just as easy to do something like this:
add(new Form[Person](form, model) {
override def onInitialize: add (new TextArea[String](text, (getModel -
text)) {
override def isVisible: Boolean = false
})
})
Thanks for the reply -
Yes it would be as simple as that - but again, not quite as elegant (imho).
I actually think that it's more elegant to be explicit about the fact that your
components are constructed lazily during initialization rather than object
construction.
Given the recent feedback, cede that forcing onInitialize on everybody may not
be necessary, although I am still very convinced that it is the right thing to
do design-wise.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 18:56, Igor Vaynberg wrote:
On Wed, Mar 9, 2011 at 1:15 AM, Maarten Billemont lhun...@gmail.com wrote:
yep, calling overridable methods from constructors is bad - you just
made the case for making page.oninitialize() final...
No, I've made the case for this issue. Either add() should be disallowed
from the constructor (meaning onInitialize won't get called from it),
onInitialize should be made final (meaning onInitialize will do nothing when
it gets called), or Page should stop calling initialize() as a result of a
component being added, and behave like any other component does. Would you
mind addressing this third option? What exactly is the reason for Page
behaving in this special way?
page.add() is where the oninitialize cascade is initiated because that
is the earliest point at which the page instance is known. doing it
from there ensures that the page is more or less fully constructed
after it is instantiated allowing you to call methods on it.
Why should Page be a special case? Why not for Panels too?
In fact, if you take away this special casing for Page, this issue probably
wouldn't exist at all and we could go back to letting the constructor-favored
users use constructors and the others use onInitialize.
eg MyPage page=new MyPage();
page.foo() { where foo manipulates state of page's child components }
i know that is not the style you prefer to use in your applications,
but that doesnt mean no one should be able to use it.
This issue is about the fact that this style, which I've argued is flawed, is
basically causing you to finalize onInitialize, meaning no one will be able to
use the alternative. It cuts both ways, and I really don't see why
onInitialize should come out as the looser when it condones safer code.
On 09 Mar 2011, at 09:15, Igor Vaynberg wrote:
Firstly, it's my opinion that you really shouldn't be doing anything to
components directly, especially not from outside your class. As for why,
see Encapsulation and Law of Demeter.
neither of the two apply because nameeditor explicitly exposes the two
components as part of its contract via public getters.
Allow me to remind you:
More formally, the Law of Demeter for functions requires that a method M of
an object O may only invoke the methods of the following kinds of objects:
• O itself
• M's parameters
• any objects created/instantiated within M
• O's direct component objects
• a global variable, accessible by O, in the scope of M
Making your components available via getters does not excuse anything. The
list does not include invoke methods on any objects created by any objects
created within M, for good reason.
yes, and if we follow this good reason then i would have to add the
following methods:
nameditor {
setfirstnamevisible() {}
setlastnamevisible() {}
setfirstnameenabled() {}
setlastnameenabled() {}
setfirstnamerequired() {}
setlastnamerequired() {}
addfirstnamevalidator() {}
addlastnamevalidator() {}
setfirstnamelabel() {}
setlastnamelabel() {}
}
just to name a few, and all they do is forward stuff to the two inner
components. sounds like a lot of fun...
Actually, that would be a workaround to hack away a warning your IDE might give
you about the Law of Demeter. The point of the practice is that outside of
NameEditor, you shouldn't be doing anything that requires knowledge of how
NameEditor works. Which means you shouldn't be exposing any of its components,
and definitely none of its components' properties. If you want to do something
to your NameEditor that changes the way it shows your name, you should express
that in terms that make sense for a name editor.
new NameEditor(NameEditorMode.FIRST_NAME_ONLY);
Or whatever API makes sense to you. Just don't expose NameEditor's guts.
Also, I really don't like condoning get(String), it's nasty and very
type-unfriendly. It also breaks as soon as you do any refactoring in your
component hierarchy.
yes, i traded off some refactorability for better memory footprint.
imho a perfectly valid trade off when memory and space are costly.
there are still problems with this:
*you still have the two extra memory slots that are a complete waste
here - component references
You're talking about the cost of a reference to a component. It's not like
you've got a COPY of the component in your field. And no, it's not a good
trade-off. You're writing Java applications, you'll be deploying in Java
application containers, you're working with a web framework that goes to
great lengths to help the container provide solid clustering. Your memory
footprint is absolutely subordinate to decently maintainable and
compile-time checked code. If you're a developer that doesn't appreciate
the latter, you'll find that you can be a lot more flexible using a language
with weak type checking, at the
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Wed, Mar 9, 2011 at 11:54 AM, Maarten Billemont lhun...@gmail.com wrote:
On 09 Mar 2011, at 18:56, Igor Vaynberg wrote:
On Wed, Mar 9, 2011 at 1:15 AM, Maarten Billemont lhun...@gmail.com wrote:
yep, calling overridable methods from constructors is bad - you just
made the case for making page.oninitialize() final...
No, I've made the case for this issue. Either add() should be disallowed
from the constructor (meaning onInitialize won't get called from it),
onInitialize should be made final (meaning onInitialize will do nothing
when it gets called), or Page should stop calling initialize() as a result
of a component being added, and behave like any other component does.
Would you mind addressing this third option? What exactly is the reason
for Page behaving in this special way?
page.add() is where the oninitialize cascade is initiated because that
is the earliest point at which the page instance is known. doing it
from there ensures that the page is more or less fully constructed
after it is instantiated allowing you to call methods on it.
Why should Page be a special case? Why not for Panels too?
oninitialize() is an atomic callback that notifies components when the
page becomes available. the page is special because since a page is
always available to itself it doesnt need such a callback. how is that
for a rationalization... :)
you are mixing a generic post-construct callback with a more specific
usecase of oninitialize()
In fact, if you take away this special casing for Page, this issue probably
wouldn't exist at all and we could go back to letting the constructor-favored
users use constructors and the others use onInitialize.
that may very well be true. but weve come a long way from the
beginning of this thread which was: forbid add() in constructors.
eg MyPage page=new MyPage();
page.foo() { where foo manipulates state of page's child components }
i know that is not the style you prefer to use in your applications,
but that doesnt mean no one should be able to use it.
This issue is about the fact that this style, which I've argued is flawed, is
basically causing you to finalize onInitialize, meaning no one will be able
to use the alternative. It cuts both ways, and I really don't see why
onInitialize should come out as the looser when it condones safer code.
On 09 Mar 2011, at 09:15, Igor Vaynberg wrote:
Firstly, it's my opinion that you really shouldn't be doing anything to
components directly, especially not from outside your class. As for why,
see Encapsulation and Law of Demeter.
neither of the two apply because nameeditor explicitly exposes the two
components as part of its contract via public getters.
Allow me to remind you:
More formally, the Law of Demeter for functions requires that a method M
of an object O may only invoke the methods of the following kinds of
objects:
• O itself
• M's parameters
• any objects created/instantiated within M
• O's direct component objects
• a global variable, accessible by O, in the scope of M
Making your components available via getters does not excuse anything. The
list does not include invoke methods on any objects created by any objects
created within M, for good reason.
yes, and if we follow this good reason then i would have to add the
following methods:
nameditor {
setfirstnamevisible() {}
setlastnamevisible() {}
setfirstnameenabled() {}
setlastnameenabled() {}
setfirstnamerequired() {}
setlastnamerequired() {}
addfirstnamevalidator() {}
addlastnamevalidator() {}
setfirstnamelabel() {}
setlastnamelabel() {}
}
just to name a few, and all they do is forward stuff to the two inner
components. sounds like a lot of fun...
Actually, that would be a workaround to hack away a warning your IDE might
give you about the Law of Demeter. The point of the practice is that outside
of NameEditor, you shouldn't be doing anything that requires knowledge of how
NameEditor works. Which means you shouldn't be exposing any of its
components, and definitely none of its components' properties. If you want
to do something to your NameEditor that changes the way it shows your name,
you should express that in terms that make sense for a name editor.
new NameEditor(NameEditorMode.FIRST_NAME_ONLY);
Or whatever API makes sense to you. Just don't expose NameEditor's guts.
the two components are not considered guts. the nameeditor
encapsulates the markup used to render the two components in my
application, as well as a good set of defaults. however, it leaves
room open for overriding those defaults. there is nothing wrong with
this design.
Also, I really don't like condoning get(String), it's nasty and very
type-unfriendly. It also breaks as soon as you do any refactoring in
your component hierarchy.
yes, i traded off some refactorability for better memory footprint.
imho a perfectly valid trade
RE: CompoundPropertyModel deprecated in 1.5 - what is the replacement?
My bad! I was had done s search on CompoundPropertyModel and BoundCompoundPropertyModel showed up in the deprecated list but I just saw the highlighted CompountPropertyModel part... =] Sorry, CompoundPropertyModel is not deprecated in 1.5, it's BoundCompoundPropertyModel that is. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using jQuery with Wicket
Hi, I think you've forgotten adding code Hi, I am calling second page onsubmit method of the first page as: setResponsePage(PGSecond.class); and on the second page label is added as: Thanx. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Models doco page typo?
I didn't realize that so I found this line on that page a bit confusing: The IModel interface was simplified in Wicket 2.0 Maybe it should say: The IModel interface was simplified in Wicket 1.4 now that 2.0 doesn't exist and the change was actually made in 1.4. -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Thursday, 10 March 2011 6:08 AM To: users@wicket.apache.org Subject: Re: Models doco page typo? Wicket 2 has been discontinued. Most of the features in it has been merged to 1.4/1.5. Some of them was considered unsuccessful and dropped. On Wed, Mar 9, 2011 at 9:46 AM, Coleman, Chris chris.cole...@thalesgroup.com.au wrote: At the bottom of this page: https://cwiki.apache.org/WICKET/working-with-wicket-models.html it says that the IModel interface was simplified in Wicket 2.0... should that really be Wicket 1.2? Never heard of Wicket 2 and I can see the 'new' style interface in Javadocs for 1.5. DISCLAIMER:- - - This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. - - -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 21:42, Igor Vaynberg wrote: oninitialize() is an atomic callback that notifies components when the page becomes available. the page is special because since a page is always available to itself it doesnt need such a callback. how is that for a rationalization... :) Only, you're special-casing initialize() in Pages so that onInitialize() gets called as soon as the page is available, only to then disallow developers from using onInitialize() by making it final. Kind of defeats the whole point, doesn't it. And I can't see initialize() doing anything else that the developer might notice. So really, just don't do it. In fact, if you take away this special casing for Page, this issue probably wouldn't exist at all and we could go back to letting the constructor-favored users use constructors and the others use onInitialize. that may very well be true. but weve come a long way from the beginning of this thread which was: forbid add() in constructors. We have come a long way, but if onInitialize didn't behave this way for pages, that would be an ideal solution to the issue that wouldn't force onInitialize or the constructor (or a lame onConfigure hack). interesting because in the beginning of this thread you wanted to blindly castrate constructors :) I explained the issue and proposed solutions. One of them involved not creating component hierarchies from the constructors. I wouldn't call that castrating: You still get to use them for what they're supposed to do: initialize your instance's state. i have proposed a way to deal with the issue. you can create your own one-time callback in the page from inside onconfigure(). So to round up, the proposed solutions are: 1. Forbid add() in constructor. 2. Forbid onInitialize() in pages (and fake one with onConfigure code that really has nothing to do with configuring but is onInitialize code in a block that requires a test of an instance field that takes up a whole boolean field in your page state, and do that for each of your pages). 3. Don't initialize() on add() in pages. * -1 to forbid add() from constructors * +0 to delay oninitialize() cascade until right before the first call to onconfigure() So that's [1] and [3] out the window, does that mean you vote +1 for [2]? Because as I mentioned before, you can't in all honesty argue the case of leaving the door open for add() in constructors if the developer want to do that and slam the door shut for add() in onInitialize() if the developer wants to do that. Perhaps we can add a [4]: 4. Allow both and ignore the fact that mixing them will break things in pages. Heck, if we can allow doing potentially bad things in constructors because the bad is rare anyway, why not, right? My vote, in order of preference, would be [1], [3], [4], [2]. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CompoundPropertyModel deprecated in 1.5 - what is the replacement?
On 09 Mar 2011, at 22:01, Chris Colman wrote: Sorry, CompoundPropertyModel is not deprecated in 1.5, it's BoundCompoundPropertyModel that is. Too bad :-) Really, you use normal models and LDMs, or BindGen (http://code.google.com/p/bindgen-wicket/) and make your code type-safe. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: CompoundPropertyModel deprecated in 1.5 - what is the replacement?
What is wrong with compoundpropertymodel (pre 1.5)? -Original Message- From: Maarten Billemont [mailto:lhun...@gmail.com] Sent: Wednesday, March 09, 2011 4:30 PM To: users@wicket.apache.org Subject: Re: CompoundPropertyModel deprecated in 1.5 - what is the replacement? On 09 Mar 2011, at 22:01, Chris Colman wrote: Sorry, CompoundPropertyModel is not deprecated in 1.5, it's BoundCompoundPropertyModel that is. Too bad :-) Really, you use normal models and LDMs, or BindGen (http://code.google.com/p/bindgen-wicket/) and make your code type-safe. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
Just a thought: Surely there must be a way to support both styles of 'construction' (I use that term loosely) within the one framework. Perhaps a runtime switch in the properties could dictate the 'construction' mode. You could leave the default as 'traditional wicket' mode but in 'two phase' construction mode a clear two phase constructor/init strategy is used whereby init is called only after parent object construction is complete so that all virtual method calls will be made from within the init method and so guatrateed to be operating on a 'fully constructed object' instead of the current situation where it can be operating on a partically constructed parent object - nasty! (I admit it is more dangerous in languages like C++ but it can still cause significant problems in Java). In this two phase mode exceptions could be thrown if an attempt is made to do something which is dangerous or would go against the strategy. That means everybody used to other frameworks where a separate 'init' phase takes place after parent object construction is complete will be happy because they can switch to 'two phase' mode but at the same time all existing wicket code will continue to work unchanged. -Original Message- From: Maarten Billemont [mailto:lhun...@gmail.com] Sent: Thursday, 10 March 2011 8:28 AM To: Igor Vaynberg Cc: users@wicket.apache.org Subject: Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages On 09 Mar 2011, at 21:42, Igor Vaynberg wrote: oninitialize() is an atomic callback that notifies components when the page becomes available. the page is special because since a page is always available to itself it doesnt need such a callback. how is that for a rationalization... :) Only, you're special-casing initialize() in Pages so that onInitialize() gets called as soon as the page is available, only to then disallow developers from using onInitialize() by making it final. Kind of defeats the whole point, doesn't it. And I can't see initialize() doing anything else that the developer might notice. So really, just don't do it. In fact, if you take away this special casing for Page, this issue probably wouldn't exist at all and we could go back to letting the constructor-favored users use constructors and the others use onInitialize. that may very well be true. but weve come a long way from the beginning of this thread which was: forbid add() in constructors. We have come a long way, but if onInitialize didn't behave this way for pages, that would be an ideal solution to the issue that wouldn't force onInitialize or the constructor (or a lame onConfigure hack). interesting because in the beginning of this thread you wanted to blindly castrate constructors :) I explained the issue and proposed solutions. One of them involved not creating component hierarchies from the constructors. I wouldn't call that castrating: You still get to use them for what they're supposed to do: initialize your instance's state. i have proposed a way to deal with the issue. you can create your own one-time callback in the page from inside onconfigure(). So to round up, the proposed solutions are: 1. Forbid add() in constructor. 2. Forbid onInitialize() in pages (and fake one with onConfigure code that really has nothing to do with configuring but is onInitialize code in a block that requires a test of an instance field that takes up a whole boolean field in your page state, and do that for each of your pages). 3. Don't initialize() on add() in pages. * -1 to forbid add() from constructors * +0 to delay oninitialize() cascade until right before the first call to onconfigure() So that's [1] and [3] out the window, does that mean you vote +1 for [2]? Because as I mentioned before, you can't in all honesty argue the case of leaving the door open for add() in constructors if the developer want to do that and slam the door shut for add() in onInitialize() if the developer wants to do that. Perhaps we can add a [4]: 4. Allow both and ignore the fact that mixing them will break things in pages. Heck, if we can allow doing potentially bad things in constructors because the bad is rare anyway, why not, right? My vote, in order of preference, would be [1], [3], [4], [2]. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 23:31, Chris Colman wrote: Surely there must be a way to support both styles of 'construction' (I use that term loosely) within the one framework. My proposed [3] and [4] already does that without an external configuration option that would confuse things about as much as JSF's faces-config.xml and all that good stuff. But sure, you could implement [1] and allow the developer to turn off the RTE from an Application setting. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CompoundPropertyModel deprecated in 1.5 - what is the replacement?
On 09 Mar 2011, at 22:36, Brown, Berlin [GCG-PFS] wrote: On 09 Mar 2011, at 22:01, Chris Colman wrote: Sorry, CompoundPropertyModel is not deprecated in 1.5, it's BoundCompoundPropertyModel that is. Too bad :-) Really, you use normal models and LDMs, or BindGen (http://code.google.com/p/bindgen-wicket/) and make your code type-safe. What is wrong with compoundpropertymodel (pre 1.5)? Your model object is not used in a type-safe and refactorable/compile-time checked (read maintainable) manner. Read the bindget URL I linked for more info or perhaps more informative: http://wicketinaction.com/2009/11/removing-fragile-string-expressions-from-wicket-code/ Usually though, I tend to just use normal IModels, Models, AROMs and LDMs, though. Those are perfectly safe thanks to Java's generics, albeit a bit verbose no thanks to Java's lacking support for closures. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Fate of CompressedResourceReference in Wicket 1.5?
Hi, CompressedResourceReference in trunk is basically empty and has the comment TODO NG. A quick search through the source leads me to believe that IResourceSettings#getDisableGZipCompression() is also unused. In other words, gzipping of resources is not implemented in Wicket 1.5. Are there plans to do so? Part of me thinks that maybe this feature should be dropped, as compression makes more sense to handle at the servlet container or web server layer (e.g. mod_deflate). Thoughts? -- Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RestartResponseAtInterceptPageException not redirecting to source Page
Hi, I have a RestartResponseAtInterceptPageException working correctly in
one case and not so in another.
I have a Login page with a LoginForm. In this form's onSubmit method, right
after the user validation takes place, I have:
if(!continueToOriginalDestination()) {
setResponsePage(Dashboard.class);
}
When this is called form the following Page, it works correctly (the users
gets redirected to the Login page, and once he logs in correctly, he is
redirected back to the page below):
public class PublishItem {
public PublishItem() {
if(!UserLoggedInSession.get().isLoggedIn()) {
UserLoggedInSession.get().getFeedbackMessages().add(getPage(), You need to
Sign in before you can publish!, FeedbackMessage.INFO);
throw new RestartResponseAtInterceptPageException(Login.class);
}
}
}
However, when this same logics is applied from within a Link's onClick
method, it does not work:
AnotherPage.java
Link signinLink = new Link(siginLink) {
public void onClick() {
UserLoggedInSession.get().getFeedbackMessages().add(getPage(), Signin
before adding a comment!, FeedbackMessage.INFO);
throw new RestartResponseAtInterceptPageException(Login.class);
}
};
signinLink.setVisible(!userLoggedIn);
add(signinLink);
In this second case, the user does get redirected to the Login page, and
once the correct username/password combination is entered, he actually logs
into the system. The problem is that the Login page simply refreshes, and
does not get redirected back to AnotherPage.java
Any help is appreciated.
Thanks.
Re: RestartResponseAtInterceptPageException not redirecting to source Page
On 10 Mar 2011, at 04:25, Henrique Boregio wrote:
Hi, I have a RestartResponseAtInterceptPageException working correctly in
one case and not so in another.
I have a Login page with a LoginForm. In this form's onSubmit method, right
after the user validation takes place, I have:
if(!continueToOriginalDestination()) {
setResponsePage(Dashboard.class);
}
In what wicket method is this?
When this is called form the following Page, it works correctly (the users
gets redirected to the Login page, and once he logs in correctly, he is
redirected back to the page below):
public class PublishItem {
public PublishItem() {
if(!UserLoggedInSession.get().isLoggedIn()) {
UserLoggedInSession.get().getFeedbackMessages().add(getPage(), You need to
Sign in before you can publish!, FeedbackMessage.INFO);
throw new RestartResponseAtInterceptPageException(Login.class);
}
}
}
getPage().info(You need to Sign in ..);
Also, you should probably do this check in an onBeforeRender, not in a
constructor.
However, when this same logics is applied from within a Link's onClick
method, it does not work:
AnotherPage.java
Link signinLink = new Link(siginLink) {
public void onClick() {
UserLoggedInSession.get().getFeedbackMessages().add(getPage(), Signin
before adding a comment!, FeedbackMessage.INFO);
throw new RestartResponseAtInterceptPageException(Login.class);
}
};
signinLink.setVisible(!userLoggedIn);
add(signinLink);
Your Link should override onConfigure and in there you should
setVisible(!userLoggedIn) instead of only performing this check on page
construction.
In this second case, the user does get redirected to the Login page, and
once the correct username/password combination is entered, he actually logs
into the system. The problem is that the Login page simply refreshes, and
does not get redirected back to AnotherPage.java
But none of those tips likely have anything to do with what you're saying the
problem is. I suggest you attach a debugger on the point where you complete
log-in and see what flow wicket follows and where it deviates from what you
expect it to do.
Any help is appreciated.
Thanks.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Fate of CompressedResourceReference in Wicket 1.5?
File a ticket please. On Thu, Mar 10, 2011 at 3:01 AM, Matt Brictson m...@55minutes.com wrote: Hi, CompressedResourceReference in trunk is basically empty and has the comment TODO NG. A quick search through the source leads me to believe that IResourceSettings#getDisableGZipCompression() is also unused. In other words, gzipping of resources is not implemented in Wicket 1.5. Are there plans to do so? Part of me thinks that maybe this feature should be dropped, as compression makes more sense to handle at the servlet container or web server layer (e.g. mod_deflate). Thoughts? -- Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
