Re: client side validation
That doesn't work. Sometimes you want to add multiple behaviors to the same event. Wicket doesn't support that. Erik. James Carman wrote: > So, create an IComponentInstantiationListener that looks for Forms and > adds the behavior to them. > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
Thanks for the info Igor. On Jan 27, 2008 9:33 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > mixing validators and behaviors has been on our todo list for a while, > but we couldnt do it cleanly in 1.3 because it would mean an api > break. > > we will do it for 1.4 > > as far as getting the name of formcomponent, that is already possible > through ibehavior.bind(component) > > -igor > > > On Jan 27, 2008 12:07 PM, Flemming Boller <[EMAIL PROTECTED]> > wrote: > > Hi > > > > Just a thought about client side validation. > > > > I have looked at simple validation like maxlength, min length stuff like > > that. The jQuery > > validation plugin solves that easily. > > > > My idea was to inherit from the corresponding wicket-validator and > implement > > IBehavoir. > > Then I would be able to generate javascript based on the validator. > > > > I would then add my "javascript-enabled-validator " to the form classes. > > > > Would that be a way to go? comments anyone? > > > > The problem I see is to get the name attribute from the formcomponent, > > but I guess I have to look at the Javadoc for wicket > > > > /Flemming > > > > > > > > > > On Jan 27, 2008 4:00 PM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > > > I've spent the past couple weeks investigating Wicket's support for > > > client side validation. IMO, using Ajax for validation in Wicket is > > > really amazing. Lots of folks are touting "javascript validation" > > > right now, but I think Wicket has a definite advantage because the > > > Ajax validation *reuses* all of your server side validation for free! > > > This might be worth mentioning on the feature list somewhere and I'd > > > be interested in any comments. > > > > > > Ryan > > > > > > - > > > 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] > >
[WicketStuff-Scriptaculous] DragNDrop problem in IE6/IE7.
Hi, I have encountered a DragNDrop problem using wicketStuff-scriptaculous in IE6/IE7. The DragNDrop only work for the first time, but subsequently, the draggable object is no longer draggable. FYI, this problem doesn't exist in Firefox and it can be reproduced in wicket-contrib-scriptaculous-examples. Any hints? Thanks in advance. Regards Boon Ping. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Any Example or doucument of Rich Edit, such as YUI,FCK
Hello Igor Vaynberg, The YUI-example get a Exception: org.apache.wicket.WicketRuntimeException:Application class org.wicketstuff.yui.example.pages.YuiApplication must be a subclass of WebApplication Well, I have run the cmd "mvn install", and everything is run ok. Than, I copy the *.war to webapp directory. What's wrong with that? Best regards, === At 2008-01-28, 09:46:37 you wrote: === >after you check out the source run mvn install - that will fetch the >necessary jars. > >-igor > > >On Jan 27, 2008 5:44 PM, Mead <[EMAIL PROTECTED]> wrote: >> Hello Igor Vaynberg, >>I have check the code from wicket stuff's svn >> (https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/ ) >> both the example and source of YUI & TinyMCE! >> but there are too many error, most is missing the "jar". >> How to get the correlation "jar"? >> I have no clue at all! >> >> >> >> Best regards, >> >> === At 2008-01-26, 01:05:21 you wrote: === >> >> >> >there is wicket-contrib-tinymce in wicketstuff >> > >> >-igor >> > >> > >> >On Jan 25, 2008 1:59 AM, Mead <[EMAIL PROTECTED]> wrote: >> >> Hello All, >> >> Any Example or doucument of Rich Edit, such as YUI,FCK >> >> How to integration with wicket? >> >> There is so little doc about that's >> >> thanks to provide help >> >> >> >> Best regards, >> >> Mead >> >> [EMAIL PROTECTED] >> >> 2008-01-25 >> >> >> >> >> >> >> >> - >> >> 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] >> > >> >. >> >> = = = = = = = = = = = = = = = = = = = = >> >> Mead >> [EMAIL PROTECTED] >> 2008-01-28 >> >> >> >> >> >> - >> 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] > = = = = = = = = = = = = = = = = = = = = Mead [EMAIL PROTECTED] 2008-01-28 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Any Example or doucument of Rich Edit, such as YUI,FCK
after you check out the source run mvn install - that will fetch the necessary jars. -igor On Jan 27, 2008 5:44 PM, Mead <[EMAIL PROTECTED]> wrote: > Hello Igor Vaynberg, >I have check the code from wicket stuff's svn > (https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/ ) > both the example and source of YUI & TinyMCE! > but there are too many error, most is missing the "jar". > How to get the correlation "jar"? > I have no clue at all! > > > > Best regards, > > === At 2008-01-26, 01:05:21 you wrote: === > > > >there is wicket-contrib-tinymce in wicketstuff > > > >-igor > > > > > >On Jan 25, 2008 1:59 AM, Mead <[EMAIL PROTECTED]> wrote: > >> Hello All, > >> Any Example or doucument of Rich Edit, such as YUI,FCK > >> How to integration with wicket? > >> There is so little doc about that's > >> thanks to provide help > >> > >> Best regards, > >> Mead > >> [EMAIL PROTECTED] > >> 2008-01-25 > >> > >> > >> > >> - > >> 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] > > > >. > > = = = = = = = = = = = = = = = = = = = = > > Mead > [EMAIL PROTECTED] > 2008-01-28 > > > > > > - > 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: Filter data with wicket
suppose you have a single text keyword box:
class searchpage extends webpage {
private String keywords;
public searchpage() {
Form form=new Form("form");
form.add(new TextBox("keywords", new PropertyModel(this, "keywords")));
add(new DataView("results", new MyDataProvider()) {
protected void populateitem(item) {
..
}
});
}
private class MyDataProvider implements IDataProvider {
public Iterator iterator(int first, int count) {
return query(first, count, keywords);
}
public int size() {
return size(keywords);
}
}
}
-igor
On Jan 27, 2008 4:59 PM, Mathias P.W Nilsson <[EMAIL PROTECTED]> wrote:
>
> I don't quit follow what you mean since I'm a newbie. Can you please explain
> in a little more detail or give me some pointers.
> --
> View this message in context:
> http://www.nabble.com/Filter-data-with-wicket-tp15124809p15126484.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]
Re: Re: Any Example or doucument of Rich Edit, such as YUI,FCK
Hello Igor Vaynberg, I have check the code from wicket stuff's svn (https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/ ) both the example and source of YUI & TinyMCE! but there are too many error, most is missing the "jar". How to get the correlation "jar"? I have no clue at all! Best regards, === At 2008-01-26, 01:05:21 you wrote: === >there is wicket-contrib-tinymce in wicketstuff > >-igor > > >On Jan 25, 2008 1:59 AM, Mead <[EMAIL PROTECTED]> wrote: >> Hello All, >> Any Example or doucument of Rich Edit, such as YUI,FCK >> How to integration with wicket? >> There is so little doc about that's >> thanks to provide help >> >> Best regards, >> Mead >> [EMAIL PROTECTED] >> 2008-01-25 >> >> >> >> - >> 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] > >. = = = = = = = = = = = = = = = = = = = = Mead [EMAIL PROTECTED] 2008-01-28 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Controlling render for DropDownChoice
see Select, SelectOption, SelectOptions in wicket-extensions. that
should give you complete control over the markup.
-igor
On Jan 25, 2008 4:47 PM, Mathias P.W Nilsson <[EMAIL PROTECTED]> wrote:
>
> Is there anyway to control the rendering of a dropdownchoice?
> I don't mean implementing IChoiceRenderer but to set style on option tag in
> select parent tag.
> I tried to indent the name in a select tag by implementing the
> IChoiceRenderer but it doens't work.
> See getDisplayValue
>
>
>
> class TestChoiceRenderer implements IChoiceRenderer {
>
> public Object getDisplayValue(Object object) {
> // I don't know if it can be anything other...??
> if (object instanceof se.boardstore.model.Category) {
> se.boardstore.model.Category so =
> (se.boardstore.model.Category) object;
> if( ! so.isParent() ) {
> return " " + so.getName();
> }else{
> return so.getName();
> }
>
>
> }
> return null;
> }
>
> public String getIdValue(Object key, int index) {
> // I don't know if it can be anything other...??
> if (key instanceof se.boardstore.model.Category) {
> se.boardstore.model.Category selectOption =
> (se.boardstore.model.Category) key;
> return selectOption.getId().toString();
>
> }
> return null;
> }
>
> }
>
> --
> View this message in context:
> http://www.nabble.com/Controlling-render-for-DropDownChoice-tp15100129p15100129.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]
Re: Filter data with wicket
I don't quit follow what you mean since I'm a newbie. Can you please explain in a little more detail or give me some pointers. -- View this message in context: http://www.nabble.com/Filter-data-with-wicket-tp15124809p15126484.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]
Re: Controlling render for DropDownChoice
You can only controll the select and not a single option using this. At least not all browsers -- View this message in context: http://www.nabble.com/Controlling-render-for-DropDownChoice-tp15100129p15126445.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]
Re: Controlling render for DropDownChoice
Use stylesheets:
select.yourCssClass option {
background-color: pink;
color: green;
}
Frank
On Jan 26, 2008 1:47 AM, Mathias P.W Nilsson <[EMAIL PROTECTED]> wrote:
>
> Is there anyway to control the rendering of a dropdownchoice?
> I don't mean implementing IChoiceRenderer but to set style on option tag
> in
> select parent tag.
> I tried to indent the name in a select tag by implementing the
> IChoiceRenderer but it doens't work.
> See getDisplayValue
>
>
>
> class TestChoiceRenderer implements IChoiceRenderer {
>
>public Object getDisplayValue(Object object) {
>// I don't know if it can be anything other...??
>if (object instanceof se.boardstore.model.Category) {
>se.boardstore.model.Category so =
> (se.boardstore.model.Category) object;
>if( ! so.isParent() ) {
>return " " + so.getName();
>}else{
>return so.getName();
>}
>
>
>}
>return null;
>}
>
>public String getIdValue(Object key, int index) {
>// I don't know if it can be anything other...??
>if (key instanceof se.boardstore.model.Category) {
>se.boardstore.model.Category selectOption =
> (se.boardstore.model.Category) key;
>return selectOption.getId().toString();
>
>}
>return null;
>}
>
>}
>
> --
> View this message in context:
> http://www.nabble.com/Controlling-render-for-DropDownChoice-tp15100129p15100129.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]
>
>
Re: Filter data with wicket
Depending on the component you use to display the list there are a few differences in putting it all together but generally you should create a bean containing all your filter options. you can then pass the bean to your query and adjust it accordingly. If you use a ListView or DataView you have to make your own form to capture input for the filter, if you use a DataTable then that can be done automatically for you. Maurice On Jan 27, 2008 11:02 PM, Mathias P.W Nilsson <[EMAIL PROTECTED]> wrote: > > Hi! > > I have a design question for wicket. > > In my Article page the user can filter the articles in many ways, by > category, brand, price, department, gender etc. I wan't to Use the same > wicketpage for the Article list. What is the best approach with wicket? > > make New ArticlePage().setDepartment( requestedDepartment ); and have > different set, get methods for the filter objects or can someone point me in > the right direction? > > Thanks > > -- > View this message in context: > http://www.nabble.com/Filter-data-with-wicket-tp15124809p15124809.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]
Re: Strange Sql exception accesing Wicket page
Yes, this is an improperly configured connection pool. In Tomcat you would look at these settings such as the following: timeBetweenEvictionRunsMillis numTestsPerEvictionRun minEvictableIdleTimeMillis - Scott On Jan 27, 2008 7:08 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > that looks like a database pool, where connections are in and after a while > a specific connection isn't used for a long time and oracle terminates or > makes in invalid. > > configure your database pool that way that you test the connection before it > gives you the connection > > johan > > > > > On Jan 26, 2008 9:47 AM, <[EMAIL PROTECTED]> wrote: > > > Hello: > > I have several bookmarkable links that would bring up page with data > > retrieved from database via JPA/TOPLINK (EntityManager is always created > > fresh evertime data is retrieved). The servlet session time is 30 minutes > > but after several days when accessing some links, I got this > > WicketMessage: Error attaching this container for rendering . > > Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.8 (Build > > 060830)): oracle.toplink.essentials.exceptions.DatabaseException > > Internal Exception: java.sql.SQLException: ORA-02396: exceeded maximum > > idle time, please connect again > > Error Code: 2396 > > It appears that somewhere the page object is still holding on something > > causing this. After a few repeated clicking of browser refreshing button, > > the error would go away and a normal page is displayed without any other > > intervention. I'd think after a few days, all session related page > > objects would be no factors and it would work like the first time ever > > accessing it. Maybe I have problem with my jpa setup but I used similar > > methods under Seam(no EJB3) without issues so I think there maybe some > > issues with page caching? > > Thanks > -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Filter data with wicket
Hi! I have a design question for wicket. In my Article page the user can filter the articles in many ways, by category, brand, price, department, gender etc. I wan't to Use the same wicketpage for the Article list. What is the best approach with wicket? make New ArticlePage().setDepartment( requestedDepartment ); and have different set, get methods for the filter objects or can someone point me in the right direction? Thanks -- View this message in context: http://www.nabble.com/Filter-data-with-wicket-tp15124809p15124809.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]
Re: Dynamic Link Generation
Guess i misunderstood you the first time. For a layout as you described here i recommend the following: Hard code the top level menu items and either use swarm to hide the items or use the isVisible technique i told you about. use swarm to hide tabs (http://wicketstuff.org/wicketsecurity/tabs/) or copy the technique used there. For your third level, use a ListView or DataView, you can add links or if you want something really fancy panels to the items in the list, this way you don't have to know upfront which or how many reports you have. You could use a ListView for your top level menu too but since those items are known up front there is not that much to gain by doing it that way. Maurice On Jan 27, 2008 8:42 PM, <[EMAIL PROTECTED]> wrote: > Thanks for your help. I'm obviously new to Wicket. I come from roll-your-own > / Struts JSP land, and would really like to use Wicket, but the inability to > create ad-hoc links is going to be a serious design issue. My layout has a > top-level nav (Dashboard, Reports, Admin, Logout) -- obviously these can be > hard-coded in the HTML file and security enabled as you described earlier. > > I have a TabbedPanel that supports each top-level link -- ie Reports has > three tabs, 'My Reports', 'Trading', 'Compliance', etc. > > Finally, within each tab, the third nav-level would be a list of links on the > left side of the page. Thus, for the Reports-->My Reports I'd like a list of > the last 5 reports for that user on the left, and then JasperReports on the > right to display that report. Pretty simply layout. > > If you cannot create a link without first knowing what that link is in the > HTML, this simply won't work. Yes, I could create a model that places the > last 5 into a DropDownChoice, but my users are not going to like this UI. > > Hopefully this gives you a better understanding of what I'm trying to do w/ > Wicket. Can you elaborate on the 'problems of hiding an item', and will I > even be able to generate a Jasper report from within a Wicket Page? > > I kept this off the list, but will re-post if you want. > > Kind regards, > -Matt > > > > Mr Mean wrote: > > > > I'm guessing you want an alternative to display those reports because > > of the problems hiding an item? > > Why not put some logic in your model and have it decide which items to > > pass to your dropdownchoice, or adjust your query that fills the > > model. > > > > Maurice > > > > On Jan 27, 2008 6:30 PM, mgiedt <[EMAIL PROTECTED]> wrote: > >> > >> Great, that handles my security question, thanks. Now if my two users > >> have > >> access to different reports, the only way to present this is through a > >> DropDownChoice (with each report as an item) as opposed to rows of anchor > >> tags? > >> > >> Could you suggest an alternative display strategy? > >> > >> With thanks, > >> -Matt > >> -- > >> View this message in context: > >> http://www.nabble.com/Dynamic-Link-Generation-tp15114204p15121505.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] > > > > > > > Quoted from: > http://www.nabble.com/Dynamic-Link-Generation-tp15114204p15121804.html > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
mixing validators and behaviors has been on our todo list for a while, but we couldnt do it cleanly in 1.3 because it would mean an api break. we will do it for 1.4 as far as getting the name of formcomponent, that is already possible through ibehavior.bind(component) -igor On Jan 27, 2008 12:07 PM, Flemming Boller <[EMAIL PROTECTED]> wrote: > Hi > > Just a thought about client side validation. > > I have looked at simple validation like maxlength, min length stuff like > that. The jQuery > validation plugin solves that easily. > > My idea was to inherit from the corresponding wicket-validator and implement > IBehavoir. > Then I would be able to generate javascript based on the validator. > > I would then add my "javascript-enabled-validator " to the form classes. > > Would that be a way to go? comments anyone? > > The problem I see is to get the name attribute from the formcomponent, > but I guess I have to look at the Javadoc for wicket > > /Flemming > > > > > On Jan 27, 2008 4:00 PM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > I've spent the past couple weeks investigating Wicket's support for > > client side validation. IMO, using Ajax for validation in Wicket is > > really amazing. Lots of folks are touting "javascript validation" > > right now, but I think Wicket has a definite advantage because the > > Ajax validation *reuses* all of your server side validation for free! > > This might be worth mentioning on the feature list somewhere and I'd > > be interested in any comments. > > > > Ryan > > > > - > > 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: Label is driving me a *little* crazy
"Igor Vaynberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > why does it work for everyone else and not you? could you paste the > entire stack trace? > > -igor > Because I'm an idiot. Sorry group - my Eclipse environment was messed up and it wasn't building properly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
Hi Just a thought about client side validation. I have looked at simple validation like maxlength, min length stuff like that. The jQuery validation plugin solves that easily. My idea was to inherit from the corresponding wicket-validator and implement IBehavoir. Then I would be able to generate javascript based on the validator. I would then add my "javascript-enabled-validator " to the form classes. Would that be a way to go? comments anyone? The problem I see is to get the name attribute from the formcomponent, but I guess I have to look at the Javadoc for wicket /Flemming On Jan 27, 2008 4:00 PM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > I've spent the past couple weeks investigating Wicket's support for > client side validation. IMO, using Ajax for validation in Wicket is > really amazing. Lots of folks are touting "javascript validation" > right now, but I think Wicket has a definite advantage because the > Ajax validation *reuses* all of your server side validation for free! > This might be worth mentioning on the feature list somewhere and I'd > be interested in any comments. > > Ryan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: client side validation
Okay everyone, after re-reading my posts on this thread, I need to take a minute and apologize for my previous comments. They came off very argumentative and that's not what I intended. I was *so* excited to share this idea and I was kind of expecting everyone's response to be more like "WOW, this is a *fabulous* idea". =) I really appreciate the comments, and realize it's a bigger topic than I originally thought. I think I'm going to take some time to think this over and maybe write a blog or two on the subject. My original goal was to see something change with Wicket's core, but maybe all that's needed is a wiki article/cookbook for users to walk through. Thanks again, and I'm genuinely sorry if I pissed anyone off. Really! On Jan 27, 2008 12:54 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > how would specific components opt out? if i have a textarea i am going > to add tinymce behavior to, i dont want it to be validated via ajax. > > i often have validators that hit the database to check for uniquness, > etc. since every time i press a key the entire form is reprocessed, it > will add quiet a bit of overhead both to my database and to the > response time of the ajax - because optimally if the field is > standalone only that one field would be validated... > > -igor > > > On Jan 27, 2008 8:04 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > out of curiosity, would there be any interest in shipping Wicket with > > Ajax form validation turned on *by default* instead of developers > > manually adding the AjaxFormValidatingBehavior? Are there any > > drawbacks to having this be the default behavior? > > > > > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > > > I've spent the past couple weeks investigating Wicket's support for > > > client side validation. IMO, using Ajax for validation in Wicket is > > > really amazing. Lots of folks are touting "javascript validation" > > > right now, but I think Wicket has a definite advantage because the > > > Ajax validation *reuses* all of your server side validation for free! > > > This might be worth mentioning on the feature list somewhere and I'd > > > be interested in any comments. > > > > > > Ryan > > > > > > > > - > > 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
how would specific components opt out? if i have a textarea i am going to add tinymce behavior to, i dont want it to be validated via ajax. i often have validators that hit the database to check for uniquness, etc. since every time i press a key the entire form is reprocessed, it will add quiet a bit of overhead both to my database and to the response time of the ajax - because optimally if the field is standalone only that one field would be validated... -igor On Jan 27, 2008 8:04 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > out of curiosity, would there be any interest in shipping Wicket with > Ajax form validation turned on *by default* instead of developers > manually adding the AjaxFormValidatingBehavior? Are there any > drawbacks to having this be the default behavior? > > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > I've spent the past couple weeks investigating Wicket's support for > > client side validation. IMO, using Ajax for validation in Wicket is > > really amazing. Lots of folks are touting "javascript validation" > > right now, but I think Wicket has a definite advantage because the > > Ajax validation *reuses* all of your server side validation for free! > > This might be worth mentioning on the feature list somewhere and I'd > > be interested in any comments. > > > > Ryan > > > > - > 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
On Jan 27, 2008 10:35 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > On Jan 27, 2008 12:20 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > but then my app wont work. i add my own ajax behavior that knows how > > to do all this... so i would have to override some method on the form > > and tell it not to do its default thing? let me quote someone > > "Yuk...I'd hate to go through my *entire* application and replace > > org.apache.wicket.Form with com.mysite.MySpecialForm. very messy." :) > > Yes, class extension IS messy. That's the point of using behaviors, > correct? No, you wouldn't need to override a method in Form. You'd > override a method in Application or ApplicationSettings to set > "useGlobalAjaxFormValidation" will we also then have useGlobalAjaxComponentReplacement that is enabled by default? cause you know...we could... > > on startup, the application would check this setting and attach a > component instantiation listener to add this behavior to all forms. > > > your default is simply not good - updating feedback panels is rarely > > enough. also a lot of times users add a feedback panel per form > > component, so you will needlessly update tens of feedback panels > > rather then the single one that needs it. not a good default. > > If it's such a shitty default, WHY ship the > AjaxFormValidatingBehavior with Wicket at all?! What is the > "preferred" way to do this? because that class encapsulates the workflow needed to get this done, so users dont have to reinvent the wheel. its there for you to use optionally...if you want. there is really no preferred way to use it because the usecase space for this is huge across all applications. i dont really see anything wrong with rolling your own form subclass, any ide can do a search and replace for you. what next? someone wants their textfields not to trim input globally, so we have to provide a hook for that? > I *know* there are a million ways to do this, but that shouldn't stop > a framework from having good default behavior. good, so you can see where im coming from when i say what you suggest is not a good default. anyways, feel free to start a vote on this, because i fear this is a kind of thread that can get pretty long without getting anything accomplished... -igor > > > - > 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
On Jan 27, 2008 12:20 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > but then my app wont work. i add my own ajax behavior that knows how > to do all this... so i would have to override some method on the form > and tell it not to do its default thing? let me quote someone > "Yuk...I'd hate to go through my *entire* application and replace > org.apache.wicket.Form with com.mysite.MySpecialForm. very messy." :) Yes, class extension IS messy. That's the point of using behaviors, correct? No, you wouldn't need to override a method in Form. You'd override a method in Application or ApplicationSettings to set "useGlobalAjaxFormValidation" on startup, the application would check this setting and attach a component instantiation listener to add this behavior to all forms. > your default is simply not good - updating feedback panels is rarely > enough. also a lot of times users add a feedback panel per form > component, so you will needlessly update tens of feedback panels > rather then the single one that needs it. not a good default. If it's such a shitty default, WHY ship the AjaxFormValidatingBehavior with Wicket at all?! What is the "preferred" way to do this? I *know* there are a million ways to do this, but that shouldn't stop a framework from having good default behavior. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
but then my app wont work. i add my own ajax behavior that knows how to do all this... so i would have to override some method on the form and tell it not to do its default thing? let me quote someone "Yuk...I'd hate to go through my *entire* application and replace org.apache.wicket.Form with com.mysite.MySpecialForm. very messy." :) your default is simply not good - updating feedback panels is rarely enough. also a lot of times users add a feedback panel per form component, so you will needlessly update tens of feedback panels rather then the single one that needs it. not a good default. imho the best default still remains the one that adds no additional functionality that wasnt explicitly asked for. -igor On Jan 27, 2008 10:09 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > On Jan 27, 2008 12:04 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > also -1. it is trivial to do it yourself automatically like you said > > in your blog. there are plenty of usecases that wont work out of the > > box. take a common usecase where the label turns red if the field is > > in error, how do you do that out of the box? > > Umm...where did I say that there are plenty of usecases that don't > work out of the box? > > The "out of the box" behavior that wicket *could* support today is > dynamic updating of the feedback panel. No inline field messaging or > css crazyness is needed...for now... > > > - > 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
On Jan 27, 2008 12:15 PM, James Carman <[EMAIL PROTECTED]> wrote: > So, create an IComponentInstantiationListener that looks for Forms and > adds the behavior to them. Yep. That's what I posted on my blog. I'm just asking if there's any interest in making this the *default* behavior. When people evaluate wicket for the first time, they are always looking for "out of the box" functionality. Even though it's trivial "customize" your application with this behavior, the majority of users WON'T do it because it's not "out of the box". I just think it's a cool feature and other frameworks seem to be investigating client side validation... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
So, create an IComponentInstantiationListener that looks for Forms and adds the behavior to them. On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > On Jan 27, 2008 12:07 PM, James Carman <[EMAIL PROTECTED]> wrote: > > True, I guess you could create your own form superclass that does the > > default behavior you want. > > Yuk...I'd hate to go through my *entire* application and replace > org.apache.wicket.Form with com.mysite.MySpecialForm. very messy. > > that's why global component instanciation listeners were invented. =) > > - > 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
On Jan 27, 2008 12:04 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > also -1. it is trivial to do it yourself automatically like you said > in your blog. there are plenty of usecases that wont work out of the > box. take a common usecase where the label turns red if the field is > in error, how do you do that out of the box? Umm...where did I say that there are plenty of usecases that don't work out of the box? The "out of the box" behavior that wicket *could* support today is dynamic updating of the feedback panel. No inline field messaging or css crazyness is needed...for now... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
On Jan 27, 2008 12:07 PM, James Carman <[EMAIL PROTECTED]> wrote: > True, I guess you could create your own form superclass that does the > default behavior you want. Yuk...I'd hate to go through my *entire* application and replace org.apache.wicket.Form with com.mysite.MySpecialForm. very messy. that's why global component instanciation listeners were invented. =) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
True, I guess you could create your own form superclass that does the default behavior you want. On 1/27/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > also -1. it is trivial to do it yourself automatically like you said > in your blog. there are plenty of usecases that wont work out of the > box. take a common usecase where the label turns red if the field is > in error, how do you do that out of the box? > > -igor > > > On Jan 27, 2008 8:39 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > Seriously? there are companies that mandate you can't use javascript? > > Even if it's done for you and just works? > > > > Wow...that's sad, but I hardly think that's the norm and such extremes > > should not mandate system defaults. > > > > Any other arguments against such a default? The reason I'm bringing > > this up is that Tapestry ships with client side validation turned on > > by default, and I *really* like using Wicket's Ajax for form > > validation. > > > > Hey...if tapestry can do it... =) > > > > > > On Jan 27, 2008 10:17 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > -1. There are enough companies and projects that can't use or aren't > > > allowed > > > to use JavaScript, which also precludes the default enabling of such > > > functionality. > > > Martijn > > > > > > > > > On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > > > > > out of curiosity, would there be any interest in shipping Wicket with > > > > Ajax form validation turned on *by default* instead of developers > > > > manually adding the AjaxFormValidatingBehavior? Are there any > > > > drawbacks to having this be the default behavior? > > > > > > > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > > > > > > > I've spent the past couple weeks investigating Wicket's support for > > > > > client side validation. IMO, using Ajax for validation in Wicket is > > > > > really amazing. Lots of folks are touting "javascript validation" > > > > > right now, but I think Wicket has a definite advantage because the > > > > > Ajax validation *reuses* all of your server side validation for free! > > > > > This might be worth mentioning on the feature list somewhere and I'd > > > > > be interested in any comments. > > > > > > > > > > Ryan > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Buy Wicket in Action: http://manning.com/dashorst > > > Apache Wicket 1.3.0 is released > > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 > > > > > > > - > > 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
On Jan 27, 2008 11:39 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > Almost any government site/application must comply with accessibility rules > which often prohibit the use of JavaScript. section 508 compliance does *not* prohibit javascript or Ajax. You just have to be careful how you use ajax for "progressive enhancements" and that screen readers still work with the basic website. http://www.section508.gov/ Using ajax for form validation definately does not break accessability since you still get the *same behavior* with the full page refresh upon submitting the form. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
also -1. it is trivial to do it yourself automatically like you said in your blog. there are plenty of usecases that wont work out of the box. take a common usecase where the label turns red if the field is in error, how do you do that out of the box? -igor On Jan 27, 2008 8:39 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > Seriously? there are companies that mandate you can't use javascript? > Even if it's done for you and just works? > > Wow...that's sad, but I hardly think that's the norm and such extremes > should not mandate system defaults. > > Any other arguments against such a default? The reason I'm bringing > this up is that Tapestry ships with client side validation turned on > by default, and I *really* like using Wicket's Ajax for form > validation. > > Hey...if tapestry can do it... =) > > > On Jan 27, 2008 10:17 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > -1. There are enough companies and projects that can't use or aren't allowed > > to use JavaScript, which also precludes the default enabling of such > > functionality. > > Martijn > > > > > > On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > > > out of curiosity, would there be any interest in shipping Wicket with > > > Ajax form validation turned on *by default* instead of developers > > > manually adding the AjaxFormValidatingBehavior? Are there any > > > drawbacks to having this be the default behavior? > > > > > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > > > > > I've spent the past couple weeks investigating Wicket's support for > > > > client side validation. IMO, using Ajax for validation in Wicket is > > > > really amazing. Lots of folks are touting "javascript validation" > > > > right now, but I think Wicket has a definite advantage because the > > > > Ajax validation *reuses* all of your server side validation for free! > > > > This might be worth mentioning on the feature list somewhere and I'd > > > > be interested in any comments. > > > > > > > > Ryan > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Buy Wicket in Action: http://manning.com/dashorst > > Apache Wicket 1.3.0 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 > > > > - > 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: Dynamic Link Generation
I'm guessing you want an alternative to display those reports because of the problems hiding an item? Why not put some logic in your model and have it decide which items to pass to your dropdownchoice, or adjust your query that fills the model. Maurice On Jan 27, 2008 6:30 PM, mgiedt <[EMAIL PROTECTED]> wrote: > > Great, that handles my security question, thanks. Now if my two users have > access to different reports, the only way to present this is through a > DropDownChoice (with each report as an item) as opposed to rows of anchor > tags? > > Could you suggest an alternative display strategy? > > With thanks, > -Matt > -- > View this message in context: > http://www.nabble.com/Dynamic-Link-Generation-tp15114204p15121505.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]
Re: Label is driving me a *little* crazy
why does it work for everyone else and not you? could you paste the
entire stack trace?
-igor
On Jan 27, 2008 5:31 AM, Andy Czerwonka <[EMAIL PROTECTED]> wrote:
> Did something change in 1.3?
>
> http://wicketstuff.org/wicket13/compref/?wicket:bookmarkablePage=%3Aorg.apache.wicket.examples.compref.FormPage
>
> This simple example doesn't work for me either. I get a
> 1. [MarkupContainer [Component id = feedback, page =
> ca.arcticpenguin.mff.NewListingPage, path =
> 0:newListingForm:feedback.FeedbackPanel, isVisible = true, isVersioned =
> false]]I don't understand how a simple example is not working. I'm copying
> http://wicketstuff.org/wicket13/forminput/ and again, issues rendering the
> labels. It comes from the property file, and I'm assuming the properties
> file is automatically "hooked up" given I don't see any code that references
> it.
> "Erik van Oosten" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > Try removing the id attributes from the markup. Wicket likes to generate
> > this for itself.
> > You'll also need to add a FormLabel (or something named like that) to the
> > element.
> >
> > Regards,
> > Erik.
> >
> >
> > Andy Czerwonka wrote:
> >> I found this thread:
> >>
> >> http://www.mail-archive.com/users@wicket.apache.org/msg04400.html
> >>
> >> I have written similair code, but I'm getting an exception. Clearly my
> >> markup is wrong, but I can't for the life of me unnderstand why? When I
> >> inspect the code, the page contains the right things. I'm a wicket
> >> newbie to be sure, so apologies if it's a silly question.
> >>
> >> Here's the java snippet (similair to the java on the above thread)
> >>
> >> private void buildForm() {
> >>
> >> RequiredTextField nameTextField = new RequiredTextField("name");
> >>
> >> nameTextField.setLabel(new Model("Business Name"));
> >>
> >> add(nameTextField);
> >>
> >> addFieldLabel(this, nameTextField);
> >>
> >> add(new Button("saveButton"));
> >>
> >> }
> >>
> >>
> >> protected FormComponentLabel addFieldLabel(final MarkupContainer
> >> container, final FormComponent formComponent) {
> >>
> >> SimpleFormComponentLabel label = new
> >> SimpleFormComponentLabel(formComponent.getId() + "Label",
> >>
> >> formComponent);
> >>
> >> container.add(label);
> >>
> >> return label;
> >>
> >> }
> >>
> >> The markup is as follows:
> >>
> >>
> >>
> >>
> >>
> >> >> id="nameLabel">[nameLabel]
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> The error looks like:
> >>
> >> 1. [MarkupContainer [Component id = nameLabel, page =
> >> ca.arcticpenguin.mff.NewListingPage, path =
> >> 0:newListingForm:nameLabel.SimpleFormComponentLabel, isVisible = true,
> >> isVersioned = false]]
> >>
> >>
> >>
> >>
> >>
> >>
> >> -
> >> 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: client side validation
Almost any government site/application must comply with accessibility rules which often prohibit the use of JavaScript. And no, we're not going to fall for the "Foo did it" ploy :) Martijn On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > Seriously? there are companies that mandate you can't use javascript? > Even if it's done for you and just works? > > Wow...that's sad, but I hardly think that's the norm and such extremes > should not mandate system defaults. > > Any other arguments against such a default? The reason I'm bringing > this up is that Tapestry ships with client side validation turned on > by default, and I *really* like using Wicket's Ajax for form > validation. > > Hey...if tapestry can do it... =) > > On Jan 27, 2008 10:17 AM, Martijn Dashorst <[EMAIL PROTECTED]> > wrote: > > -1. There are enough companies and projects that can't use or aren't > allowed > > to use JavaScript, which also precludes the default enabling of such > > functionality. > > Martijn > > > > > > On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > > > out of curiosity, would there be any interest in shipping Wicket with > > > Ajax form validation turned on *by default* instead of developers > > > manually adding the AjaxFormValidatingBehavior? Are there any > > > drawbacks to having this be the default behavior? > > > > > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > > > > > I've spent the past couple weeks investigating Wicket's support for > > > > client side validation. IMO, using Ajax for validation in Wicket is > > > > really amazing. Lots of folks are touting "javascript validation" > > > > right now, but I think Wicket has a definite advantage because the > > > > Ajax validation *reuses* all of your server side validation for > free! > > > > This might be worth mentioning on the feature list somewhere and I'd > > > > be interested in any comments. > > > > > > > > Ryan > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Buy Wicket in Action: http://manning.com/dashorst > > Apache Wicket 1.3.0 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: client side validation
What if the Ajax stuff could be turned on globally using the web
application itself? Then, it could be customized on a per-project
basis.
public class HelloWorldApplication extends WebApplication
{
public boolean isAjaxFormValidationEnabled()
{
return true;
}
}
On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
> Seriously? there are companies that mandate you can't use javascript?
> Even if it's done for you and just works?
>
> Wow...that's sad, but I hardly think that's the norm and such extremes
> should not mandate system defaults.
>
> Any other arguments against such a default? The reason I'm bringing
> this up is that Tapestry ships with client side validation turned on
> by default, and I *really* like using Wicket's Ajax for form
> validation.
>
> Hey...if tapestry can do it... =)
>
> On Jan 27, 2008 10:17 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > -1. There are enough companies and projects that can't use or aren't allowed
> > to use JavaScript, which also precludes the default enabling of such
> > functionality.
> > Martijn
> >
> >
> > On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
> > >
> > > out of curiosity, would there be any interest in shipping Wicket with
> > > Ajax form validation turned on *by default* instead of developers
> > > manually adding the AjaxFormValidatingBehavior? Are there any
> > > drawbacks to having this be the default behavior?
> > >
> > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
> > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation
> > > >
> > > > I've spent the past couple weeks investigating Wicket's support for
> > > > client side validation. IMO, using Ajax for validation in Wicket is
> > > > really amazing. Lots of folks are touting "javascript validation"
> > > > right now, but I think Wicket has a definite advantage because the
> > > > Ajax validation *reuses* all of your server side validation for free!
> > > > This might be worth mentioning on the feature list somewhere and I'd
> > > > be interested in any comments.
> > > >
> > > > Ryan
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
> >
>
> -
> 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: Dynamic Link Generation
Great, that handles my security question, thanks. Now if my two users have access to different reports, the only way to present this is through a DropDownChoice (with each report as an item) as opposed to rows of anchor tags? Could you suggest an alternative display strategy? With thanks, -Matt -- View this message in context: http://www.nabble.com/Dynamic-Link-Generation-tp15114204p15121505.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]
London Wicket Training discount (before Google Checkout charges start)
The Wicket training courses in London, with http://herebebeasties.com/ Al Maw , are bookable using http://www.jweekend.com/dev/BookingPage/ our simple but effective Ajax cart (built on Wicket) with payments handled by Google Checkout. Since Google Checkout will globally start charging vendors for every transaction from February 1 (there will be no new charges passed on to our students), we would like to offer readers booking places on any of the 4 London Wicket courses below a special 10% discount (on top of the regular multiple place booking discount as described on our site) for bookings made up to January 31, 23:59 (GMT). All students also get a complimentary MEAPs copy of http://www.martijndashorst.com/blog/ Martijn (BTW, thanks for updating info on the http://wicket.apache.org/ Wicket site about our http://www.jweekend.com/dev/LWUGReg/ London Wicket Users Group events - over 30 people have registered so far for our February 6 event at Google) and http://chillenious.wordpress.com/ Eelco 's http://manning.com/dashorst/ Wicket in Action . Use the "promotion code": Wicket_b4_20080201 for the special discount to be applied. Apache Wicket 1.3: February 9,10 More Apache Wicket 1.3 : February 16 Getting Started with Apache Wicket 1.3: March 1 Apache Wicket 1.3: March 21,22 Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk -- View this message in context: http://www.nabble.com/London-Wicket-Training-discount-%28before-Google-Checkout-charges-start%29-tp15121297p15121297.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]
Re: client side validation
Seriously? there are companies that mandate you can't use javascript? Even if it's done for you and just works? Wow...that's sad, but I hardly think that's the norm and such extremes should not mandate system defaults. Any other arguments against such a default? The reason I'm bringing this up is that Tapestry ships with client side validation turned on by default, and I *really* like using Wicket's Ajax for form validation. Hey...if tapestry can do it... =) On Jan 27, 2008 10:17 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > -1. There are enough companies and projects that can't use or aren't allowed > to use JavaScript, which also precludes the default enabling of such > functionality. > Martijn > > > On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > out of curiosity, would there be any interest in shipping Wicket with > > Ajax form validation turned on *by default* instead of developers > > manually adding the AjaxFormValidatingBehavior? Are there any > > drawbacks to having this be the default behavior? > > > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > > > I've spent the past couple weeks investigating Wicket's support for > > > client side validation. IMO, using Ajax for validation in Wicket is > > > really amazing. Lots of folks are touting "javascript validation" > > > right now, but I think Wicket has a definite advantage because the > > > Ajax validation *reuses* all of your server side validation for free! > > > This might be worth mentioning on the feature list somewhere and I'd > > > be interested in any comments. > > > > > > Ryan > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.0 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: client side validation
-1. There are enough companies and projects that can't use or aren't allowed to use JavaScript, which also precludes the default enabling of such functionality. Martijn On 1/27/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > out of curiosity, would there be any interest in shipping Wicket with > Ajax form validation turned on *by default* instead of developers > manually adding the AjaxFormValidatingBehavior? Are there any > drawbacks to having this be the default behavior? > > On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > > > I've spent the past couple weeks investigating Wicket's support for > > client side validation. IMO, using Ajax for validation in Wicket is > > really amazing. Lots of folks are touting "javascript validation" > > right now, but I think Wicket has a definite advantage because the > > Ajax validation *reuses* all of your server side validation for free! > > This might be worth mentioning on the feature list somewhere and I'd > > be interested in any comments. > > > > Ryan > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: client side validation
out of curiosity, would there be any interest in shipping Wicket with Ajax form validation turned on *by default* instead of developers manually adding the AjaxFormValidatingBehavior? Are there any drawbacks to having this be the default behavior? On Jan 27, 2008 9:00 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > http://www.jroller.com/wireframe/entry/wicket_client_side_validation > > I've spent the past couple weeks investigating Wicket's support for > client side validation. IMO, using Ajax for validation in Wicket is > really amazing. Lots of folks are touting "javascript validation" > right now, but I think Wicket has a definite advantage because the > Ajax validation *reuses* all of your server side validation for free! > This might be worth mentioning on the feature list somewhere and I'd > be interested in any comments. > > Ryan > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange Sql exception accesing Wicket page
that looks like a database pool, where connections are in and after a while a specific connection isn't used for a long time and oracle terminates or makes in invalid. configure your database pool that way that you test the connection before it gives you the connection johan On Jan 26, 2008 9:47 AM, <[EMAIL PROTECTED]> wrote: > Hello: > I have several bookmarkable links that would bring up page with data > retrieved from database via JPA/TOPLINK (EntityManager is always created > fresh evertime data is retrieved). The servlet session time is 30 minutes > but after several days when accessing some links, I got this > WicketMessage: Error attaching this container for rendering . > Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.8 (Build > 060830)): oracle.toplink.essentials.exceptions.DatabaseException > Internal Exception: java.sql.SQLException: ORA-02396: exceeded maximum > idle time, please connect again > Error Code: 2396 > It appears that somewhere the page object is still holding on something > causing this. After a few repeated clicking of browser refreshing button, > the error would go away and a normal page is displayed without any other > intervention. I'd think after a few days, all session related page > objects would be no factors and it would work like the first time ever > accessing it. Maybe I have problem with my jpa setup but I used similar > methods under Seam(no EJB3) without issues so I think there maybe some > issues with page caching? > Thanks
Page Expired when going back to an ajax page
I have a peculiar problem that I hope can be solved by the experts! I have on my application pages a panel that is updated using an AbstractAjaxTimerBehavior to update the style attribute making it visible or not. This works just fine on the current page. If, however, I press the back button in the browser to show a page that is no longer in the current session this problem occurs: After the time of the ajax timer passes the request is sent for the panel update and the whole page is replaced by the standard "Page Expired" exception page. Is there a way to change this behaviour so it simply does not update instead of causing this exception to be thrown? Many thanks in advance, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
client side validation
http://www.jroller.com/wireframe/entry/wicket_client_side_validation I've spent the past couple weeks investigating Wicket's support for client side validation. IMO, using Ajax for validation in Wicket is really amazing. Lots of folks are touting "javascript validation" right now, but I think Wicket has a definite advantage because the Ajax validation *reuses* all of your server side validation for free! This might be worth mentioning on the feature list somewhere and I'd be interested in any comments. Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Security - runtime ACLs and Groups help plz
There is no example application (that i know of) showing what you want. Let me recap what i think you want: You have an application (probably with a basic set of roles) You want to add plugins (probably containing several pages each requiring there own special permissions to do stuff) The extra permissions for the plugin need to be picked up dynamically from the plugin itself. This is certainly more complex than what we typically use in our applications but i think i have an idea of how i would approach this: My choice would be to use swarm as it is designed to be flexible. First off i assume you have some kind off registry for you plugins so that your applications knows what is available. and that they have some kind of life cycle (init, destroy). It should not matter much if new plugins are installed while the application is running or not. Normally i would store my principals in the database and the permissions for each principal are stored in the ACL file. This has the advantage that i can use the principals to build dynamic roles (also stored in the database) and easily maintain a hierarchy between my principals ( meaning if i grant principal A i automatically get principal B). It isn't that difficult to replace the acl file with an acl database but it means your plugin is then depending on something external instead of everything being contained in the plugin jar. If you don't care about external dependencies you can go ahead and do this, if however you want the plugin to be self contained and don't want anything remaining after you have removed the plugin you could try the following: Since principals are uniquely identified by there class and name you can use just those as reference in your roles instead of foraign keys. The roles can be stored in the database without problems. I have mentioned permissions, principals and roles lets see how that picture fits together: Users are granted roles, a role is nothing more then a set of principals. Principals are dictated by the system, roles can be created dynamically by users (application manager usually) and new roles will need to be created and assigned to users after a plugin has become available. You could have the plugin create a set of default roles but they still need to be assigned to users. A principal is a set of permissions, permissions are hardcoded in your acl. the same permission might apply to several principals. So what happens if the system detects a new plugin: The plugin exposes the location of the extra acl, the system then reloads the acl, adding the extra location. the appropriate life cycle events of the plugin are triggered allowing it if necessary to create the required entries in the database. The system then continues its normal operation. To summarize, this is what i would do in a situation like this: -Each plugin has there own acl file containing the standard swarm permissions (ComponentPermission and optionally DataPermission) and maybe some of your own permissions. -The plugin either defines there own Principal class or uses the one from the application. -Principals are only referenced by class and name, not stored in a database. -The application defines a set of default Roles. -Roles are stored in a database and contain a set of Principals. -Roles can be dynamically created by selecting one or more of the available Principals. -When installing a new plugin the Hive (swarm acl) needs to be reloaded so the acl file from the plugin can be added. Let me know if this comes close to what you wanted and if it helps you or not. Maurice On Jan 27, 2008 2:34 AM, Ned Collyer <[EMAIL PROTECTED]> wrote: > > > With wicket security (either wasp/swarm, or wicket-auth-roles) can things > like Roles and Permissions be created through a web interface? > > Eg, > I need a system whereby I can add new roles (or principals) through the web > interface, and define their permission to a ACLs which are determined by > which which plugins the system is configured to use. > > Each plugin will implement some interface, and expose the ACLs that it has > available. - these will not be manually configured, and should not require > any java code change when I add a plugin to the system. > > I'm having trouble mapping this to either swarm or wicket-auth-roles. (and > trouble explaining it well ;)) > > I believe wicket-auth-roles is more component oriented, but reading about > this stuff makes my head swim. > > Can anyone either steer me in the right direction, or point at an example > that gets these ACLs and roles from a datastore at run time. > -- > View this message in context: > http://www.nabble.com/Wicket-Security---runtime-ACLs-and-Groups-help-plz-tp15115011p15115011.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] > > -
Re: Label is driving me a *little* crazy
Did something change in 1.3?
http://wicketstuff.org/wicket13/compref/?wicket:bookmarkablePage=%3Aorg.apache.wicket.examples.compref.FormPage
This simple example doesn't work for me either. I get a
1. [MarkupContainer [Component id = feedback, page =
ca.arcticpenguin.mff.NewListingPage, path =
0:newListingForm:feedback.FeedbackPanel, isVisible = true, isVersioned =
false]]I don't understand how a simple example is not working. I'm copying
http://wicketstuff.org/wicket13/forminput/ and again, issues rendering the
labels. It comes from the property file, and I'm assuming the properties
file is automatically "hooked up" given I don't see any code that references
it.
"Erik van Oosten" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Try removing the id attributes from the markup. Wicket likes to generate
> this for itself.
> You'll also need to add a FormLabel (or something named like that) to the
> element.
>
> Regards,
> Erik.
>
>
> Andy Czerwonka wrote:
>> I found this thread:
>>
>> http://www.mail-archive.com/users@wicket.apache.org/msg04400.html
>>
>> I have written similair code, but I'm getting an exception. Clearly my
>> markup is wrong, but I can't for the life of me unnderstand why? When I
>> inspect the code, the page contains the right things. I'm a wicket
>> newbie to be sure, so apologies if it's a silly question.
>>
>> Here's the java snippet (similair to the java on the above thread)
>>
>> private void buildForm() {
>>
>> RequiredTextField nameTextField = new RequiredTextField("name");
>>
>> nameTextField.setLabel(new Model("Business Name"));
>>
>> add(nameTextField);
>>
>> addFieldLabel(this, nameTextField);
>>
>> add(new Button("saveButton"));
>>
>> }
>>
>>
>> protected FormComponentLabel addFieldLabel(final MarkupContainer
>> container, final FormComponent formComponent) {
>>
>> SimpleFormComponentLabel label = new
>> SimpleFormComponentLabel(formComponent.getId() + "Label",
>>
>> formComponent);
>>
>> container.add(label);
>>
>> return label;
>>
>> }
>>
>> The markup is as follows:
>>
>>
>>
>>
>>
>> > id="nameLabel">[nameLabel]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> The error looks like:
>>
>> 1. [MarkupContainer [Component id = nameLabel, page =
>> ca.arcticpenguin.mff.NewListingPage, path =
>> 0:newListingForm:nameLabel.SimpleFormComponentLabel, isVisible = true,
>> isVersioned = false]]
>>
>>
>>
>>
>>
>>
>> -
>> 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]
