FormComponent markup
Hello *,
I have two classes, along the lines of:
class A
{
String id;
}
class B
{
A manyBToOneA;
String description;
}
I want to provide a single form such as:
Id:
Default description:
[Submit]
I plan to use two subclasses of FormComponent, so that one uses IModelA, the
other usaes IModelB and they are reusable in other forms.
What would be the HTML markup for the main form? Should I use two
wicket:panel also if FormComponent is not a Panel? Should I use two div
wicket:id=...? What if I prefer to avoid div-ing the different fields of
the form?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Style Modifier
yes,appears useful to me :) however not sure if this should be added in wicket-core.. another way of doing the same thing is a reusable ondomreadyheaderitem using jquery's css(propertyName,value) in a neat way .. On Fri, Feb 1, 2013 at 8:14 PM, William Speirs wspe...@apache.org wrote: I created a Behavior the other night that allows one to modify the style attribute of a tag by easily adding or removing a CSS property. Why is this better/different than AttributeModifier? Because you can update a CSS property inside the style attribute. Basic usage: myComponent.add(new StyleModifier(background-color, blue)); // changes (or adds) the background-color property of the style tag on this component to blue myComponent.add(new StyleModifier(background-color)); // removes the background-color property from the style tag on this component Would anyone else find this useful? Would the devs on this list consider taking it in for the next release of Wicket (if so I can open an JIRA)? Is this already implemented and I'm just too stupid to have found it? Thanks... Bill- -- regards, Vineet Semwal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FormComponent markup
Hi,
if you are planning to subclass a FormComponent (let's say a TextField
for the id and a TextArea for the description) you don't need to use
panels and you will bind your custom components to standard form's tags
input type=text/ and texarea.../textarea
IMHO the second component should uses both models: IModelB as main
model and IModelA to retrieve the A object to assign to manyBToOneA.
Hello *,
I have two classes, along the lines of:
class A
{
String id;
}
class B
{
A manyBToOneA;
String description;
}
I want to provide a single form such as:
Id:
Default description:
[Submit]
I plan to use two subclasses of FormComponent, so that one uses IModelA, the
other usaes IModelB and they are reusable in other forms.
What would be the HTML markup for the main form? Should I use two
wicket:panel also if FormComponent is not a Panel? Should I use two div
wicket:id=...? What if I prefer to avoid div-ing the different fields of
the form?
-
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: JQuery - best practice
Hi Martin, Thank you so much! Then, I guess I am ready... All is located here (and sorry for the long preamble): https://github.com/sebfz1/wicket-jquery-ui/issues/17 Thanks best regards, Sebastien. On Thu, Jan 31, 2013 at 12:28 AM, Martin Grigorov mgrigo...@apache.orgwrote: Sebastien, I'll be glad to help you if I can! Just let me know when you are ready. On Wed, Jan 30, 2013 at 9:19 PM, Sebastien seb...@gmail.com wrote: Hi, @Pieter, Yes, a Panel was definitely not the best idea, it would have been better to have - for the moment at least - a WebMarkupContainer as I planned as the beginning. I did a try on Martin's and Ernesto's suggestion(s) (handling callbacks in behaviors, in addition to a Listener/Adapter). I need to think a little bit more on this... Anyway, I am also glad that you solved your problem. If, for any reason, you encounter unexptected issue with your solution, I can revert the Panel to a WebMarkupContainer at no cost, so it will be easy to use it in your use case. @Ernesto, About your concerns related to the age and to earn some money at the end of the month, I know exactly what your are talking about! :) @Martin, As said above, I did a try with your suggestion with a solution that works nicely. But I was not able to apply it as you wrote it (for reasons I can explain). So, I will continue to think a little bit to this to be sure I do not miss something, and, if you don't mind (I don't want to bother you with wicket-jquery-ui dev), I would like to commit a new designed behavior in github, telling you what was the original approach and what is the new one, and if you could tell me if the new one is good/relevant/wicket-way, I will really appreciate! Best regards to you all, Sebastien.
Re: JQuery - best practice
Hi Sebastien, I'll take a look at it soon. On Sat, Feb 2, 2013 at 2:59 PM, Sebastien seb...@gmail.com wrote: Hi Martin, Thank you so much! Then, I guess I am ready... All is located here (and sorry for the long preamble): https://github.com/sebfz1/wicket-jquery-ui/issues/17 Thanks best regards, Sebastien. On Thu, Jan 31, 2013 at 12:28 AM, Martin Grigorov mgrigo...@apache.org wrote: Sebastien, I'll be glad to help you if I can! Just let me know when you are ready. On Wed, Jan 30, 2013 at 9:19 PM, Sebastien seb...@gmail.com wrote: Hi, @Pieter, Yes, a Panel was definitely not the best idea, it would have been better to have - for the moment at least - a WebMarkupContainer as I planned as the beginning. I did a try on Martin's and Ernesto's suggestion(s) (handling callbacks in behaviors, in addition to a Listener/Adapter). I need to think a little bit more on this... Anyway, I am also glad that you solved your problem. If, for any reason, you encounter unexptected issue with your solution, I can revert the Panel to a WebMarkupContainer at no cost, so it will be easy to use it in your use case. @Ernesto, About your concerns related to the age and to earn some money at the end of the month, I know exactly what your are talking about! :) @Martin, As said above, I did a try with your suggestion with a solution that works nicely. But I was not able to apply it as you wrote it (for reasons I can explain). So, I will continue to think a little bit to this to be sure I do not miss something, and, if you don't mind (I don't want to bother you with wicket-jquery-ui dev), I would like to commit a new designed behavior in github, telling you what was the original approach and what is the new one, and if you could tell me if the new one is good/relevant/wicket-way, I will really appreciate! Best regards to you all, Sebastien. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
[ANNOUNCE] WicketStuff 6.5.0 is released
Hi, WicketStuff core 6.5.0 based on Apache Wicket 6.5.0 and it will become shortly available in Maven Central. Important: - wicketstuff-console has been excluded because of failing tests - wicketstuff-scala has been excluded because of failing compilation They will be included again in the release when the problems are fixed. Below is the changelog between 6.4.0 and 6.5.0. Nadeem Mohammad (11): Added editable Grid prefixed wicketstuff- for JAR module Initial Code commit of editable grid component Initial Code commit for egrid examples Added author name (editable-grid)Kept html files under resources instead of java Removed the organization (editable grid) Added proper description Added html attribute Added StyleAttribute Removed unnecessary Generics usage kbachl (5): initial fix - however, jQuery complains for obj == undefined, couldn't fix this yet initial fix#2 - problem is now the part where the callback should be used as the response data doesnt seem to work right - at least its value is jsut [Object object] oops, small glitch from debug ok, next frontier passed :D minor fixes - it seems to work on client side, but on serverside the value is not recognized, can be best seen in the Validation Example Andrea Del Bene (3): Merge pull request #1 from wicketstuff/master Merge pull request #2 from JavaLuigi/master Merge pull request #3 from wicketstuff/master Martin Grigorov (3): Merge pull request #190 from bitstorm/master Merge pull request #192 from kbachl/master Merge pull request #194 from thyzzv/master bitstorm (3): ImageUpload has been modified to support the edit form. The plugin uses the same form used by Insert/Edit Image button Merge remote-tracking branch 'origin/master' minifyed editor_plugin.js Martin Tzvetanov Grigorov (2): [objectautocomplete] Update to the new Ajax API. Make the samples application functional again. Release 6.5.0 Thijs (1): * [gmap3] Fixed Simple Ajax example * Fixed parsing of large latlon coordinates * Added option to use a Wicket component as content for a GInfoWindow.java The WicketStuff team
Re: FormComponent markup
In data sabato 2 febbraio 2013 14:54:41, Andrea Del Bene ha scritto: Hi, if you are planning to subclass a FormComponent (let's say a TextField for the id and a TextArea for the description) you don't need to use panels and you will bind your custom components to standard form's tags input type=text/ and texarea.../textarea Does that mean I'll have A.html like form input type=text ... / textarea.../textarea /form and then add my FormComponentA and FormComponentB instances directly to that Form? And that I won't have any FormComponentA.html / FormComponentB.html? IMHO the second component should uses both models: IModelB as main model and IModelA to retrieve the A object to assign to manyBToOneA. Makes sense. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OSGi Activator setup
Hmmm ... I think the classes are fine. But the issue lies more by the Filter in web.xml. Has someone an example web.xml? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/OSGi-Activator-setup-tp4655994p4656021.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: FormComponent markup
In data sabato 2 febbraio 2013 22:28:11, Lucio Crusca ha scritto: Does that mean I'll have A.html like form input type=text ... / textarea.../textarea /form and then add my FormComponentA and FormComponentB instances directly to that Form? And that I won't have any FormComponentA.html / FormComponentB.html? Probably not, I suspect I haven't understood. I tried doing like stated above, but the FormComponent constructor wants an id, so now I assume that each FormComponent subclass instance has to provide a different id. That makes me wonder again how should I write the html files. I'm not able to explain why, but the following solutions seems wrong to me: form div wicket:id=formcomponentA input type=text ... / /div div wicket:id=formcomponentB textarea.../textarea /div form
Re: OSGi Activator setup
Hi Ralf, http://www.wicket-library.com/wicket-examples-6.0.x/index.html is the application from http://central.maven.org/maven2/org/apache/wicket/wicket-examples/6.5.0/ It has pretty full web.xml Maybe it will be better if you paste your web.xml and other users can spot the error. But I think you should ask in Jonas's forums about this. I personally have no experience with it, nor with OSGi HttpService. On Sat, Feb 2, 2013 at 11:13 PM, RalfButler ralf.but...@web.de wrote: Hmmm ... I think the classes are fine. But the issue lies more by the Filter in web.xml. Has someone an example web.xml? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/OSGi-Activator-setup-tp4655994p4656021.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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: Style Modifier
@Paul Bors I would normally do the same type of thing, but I found myself in a situation where I needed to style the background color of a div that is dynamically loaded from a DB. ie, the user is free to chose whatever color they want for the div's background. A quick modification of the style element was useful here... Bill- On Sat, Feb 2, 2013 at 5:18 AM, vineet semwal vineetsemwa...@gmail.comwrote: yes,appears useful to me :) however not sure if this should be added in wicket-core.. another way of doing the same thing is a reusable ondomreadyheaderitem using jquery's css(propertyName,value) in a neat way .. On Fri, Feb 1, 2013 at 8:14 PM, William Speirs wspe...@apache.org wrote: I created a Behavior the other night that allows one to modify the style attribute of a tag by easily adding or removing a CSS property. Why is this better/different than AttributeModifier? Because you can update a CSS property inside the style attribute. Basic usage: myComponent.add(new StyleModifier(background-color, blue)); // changes (or adds) the background-color property of the style tag on this component to blue myComponent.add(new StyleModifier(background-color)); // removes the background-color property from the style tag on this component Would anyone else find this useful? Would the devs on this list consider taking it in for the next release of Wicket (if so I can open an JIRA)? Is this already implemented and I'm just too stupid to have found it? Thanks... Bill- -- regards, Vineet Semwal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
