Re: not addding componet in case of error
toggling visibility will always do,
my idea was creating the actual component only if data is available .
On Mon, Dec 14, 2009 at 2:05 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> Or just set visibility based on error
>
> On Saturday, December 12, 2009, vineet semwal
> wrote:
> > add empty webmarkupcontainers as your components,if no error,replace the
> > containers with your components
> > else
> > you don't need to replace.
> >
> >
> > On Sat, Dec 12, 2009 at 8:02 AM, Swarnim Ranjitkar >wrote:
> >
> >>
> >> I have a case where I check some error condition at the beginning of the
> >> code. If there is error I just want to display error message so
> >> basically it is
> >> if (error == true){
> >> display message
> >> } else {
> >> //render regular page
> >> add(component1)
> >> add(compnent2)
> >> }
> >>
> >> if there is error I don't have any data to generate my component. Is
> there
> >> a clean way to do this. I'm getting
> >> Unable to find component with id 'chart1image' exception. Appreciate
> your
> >> feedback
> >> thank you
> >>
> >>
> >>
> >
> >
> >
> >
> > --
> > regards,
> > Vineet Semwal
> >
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.4 increases type safety for web applications
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
regards,
Vineet Semwal
Can you attach multiple AjaxFormComponentUpdatingBehavior to the same component?
Hi all, First up must say that I love wicket, and hope to have some elements to contribute back to the community soon. I'm working on building a set of enhanced components, but have run into a problem. I am building a FormComponentPanel that has an a DropDownChoice within it. I want the panel to be able to get onchange events from the DropDown, and also require the user of this component to set their own listener. To do this I am catching the add(IBehaviours... ) method, and passing them to the internal dropdownchoice, as it is the true form component of my panel. But when I do this, it seems that the last AjaxFormComponentUpdatingBehavior added to the component wins, and none of the other behaviours watching for the onchange get notified. Is it possible to have multiple AjaxFormComponentUpdatingBehavior objects added to the same form component? Steve - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: General questions regarding Wicket roadmap and plans
But you did release them and obtained a financial benefit from the releases, the very fact that it is released to the outside world make others know of your existance and improves your exposure tremendously. The particular point under discussion originally was whether a good and active component marketplace/showcase site for Wicket will help drive the adoption and acceptance rate, as well as allow newbies like myself to pick up and use Wicket more easily. It's not about the difficulty or ease of creating/maintaining components in Wicket. Well, it's been pointed out that it's more of a resource issue to maintain such a site and I guess we'll just have to leave it at that, until someone outside the core Wicket team takes up the gauntlet and build one for the rest of us. =) Lester Jeremy Thomerson wrote: +1000 to Martijn's comment. I've released a few open source components - and none are at the level to be sold. Not because they can't be used - I do use them in production. But because there are a million use cases and I have no desire, time, or monetary reason to accommodate those use cases. Instead, if people contact me, I will either build them a custom component for hire or will allow them to pay me to add features to an open source one. -- Jeremy Thomerson http://www.wickettraining.com On Fri, Dec 4, 2009 at 2:54 AM, Martijn Dashorst wrote: The problem with pre built components is that they never, ever are exactly what you want or need. Maintaining such components for other people is what I call hell. We are in the business of creating the best Java web framework for building your own custom components with unprecedented ease. This takes enough time already. Anybody is welcome to build component libraries, open source or commercially. Our license allows for that and nobody would object to creative folks trying to earn a buck or two with their component (libraries). That this hasn't happened (yet) is mostly because it is so damned easy to create your own custom components according to your coding style that precisely fit in your application and perform exactly those task you intend them to. And conversely it is damned hard to create a finished, polished, released component. It is easy to start a component, but it is *work* to ship it. Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Modal Window Problems On Internet Explorer.
Hello guyss, I find it anoying as well I´m developing a web app and now I realize that the modal window only works in mozilla... when I try to open it wit I explorer 7 or 8 it comes up with an error page "the url does not exist" do you know how to fix that or it means our lovely java framewor "Wickets" is becoming oldfashion... Thank you very much guys!! bgooren wrote: > > I don't have this problem with the Modal Window, so my guess is that you > have some custom javascript which tries to set the focus to an element > which is either invisible or inactive. > > Bas > > > carlo c wrote: >> >> Hi, >> >> I keep on experiencing this when I try to open a modal window in IE6, 7 >> and 8. >> >> >> I don't know if any of you encountered it from before. >> >> "Can't move focus to the control because it is invisible, not enabled, >> or of a type that does not accept the focus" >> >> >> It's happeningd on Internet Explorer only and it's quite annoying. >> >> Thanks A Lot >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > > -- View this message in context: http://old.nabble.com/Modal-Window-Problems-On-Internet-Explorer.-tp26572367p26771544.html Sent from the Wicket - User 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: enclosure changes in 1.4.4
I love how simple Wicket's markup is. Please keep it clean :-)
Let's keep logic in Java and markup in HTML... no mixing.
Regards,
Daan van Etten
Op 13 dec 2009, om 18:00 heeft Martin Makundi het volgende geschreven:
What about RFE for
??
**
Martin
2009/12/13 Anton Veretennikov :
Consistency is one of wicket's strengths. My tiny vote for 1.4.4
-- Tony
On Sun, Dec 13, 2009 at 3:35 PM, Girts Ziemelis
wrote:
I also liked the behaviour - it made the code shorter, as I did
not have to
mirror the component tree in both then and else branches.
I guess it is not a big deal, except for the testing headaches -
this breaks
the code at runtime :(
I now, i know - I should have test cases covering all branches in
the form
:(
On 12/13/2009 08:14 AM, Douglas Ferguson wrote:
I did find the behavior handy, but it is easy to work around.
D/
On Dec 12, 2009, at 11:12 PM, Igor Vaynberg wrote:
i think you guys misunderstand.
i believe what we are talking about here is the requirement for
presence of components *other* then the component specified by
enclosure's child attribute.
essentially if i do this:
add(new webmarkupcontainer("container").setvisible(false));
and have this in my markup:
wicket will not throw an error even though i never added the "foo"
component to my component hierarchy because as soon as it
determins
that the container div is not visible it will skip over until the
closing tag.
the enclosures, however, as of 1.4.4 *will* throw an error for
*any*
missing child declared inside enclosure's markup *even though* the
enclosure has been determined as hidden.
hope this clears it up somewhat
-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
-
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
[Announce] First release of datatable-autocomplete wicketstuff module
Hello, I've just committed the first version of the datatable-autocomplete module into the wicketstuff-core project at wicketstuff.org. It is licensed under the Apache License version 2. The main use for this project is to have quick AJAX lookups for large static datasets. It includes a Patrica Trie (http://en.wikipedia.org/wiki/Radix_tree) which is the index and several wicket components and behaviors to tie a text field into an IDataProvider to display the results in a data table. The datatable-autocomplete-examples module works by opening up the rt.jar file in the jvm classpath and then indexing all of the methods found. You can search by the method name only but sort the results by method name, parameters or class name and see how many results there are in total after each character of the search. There are two search modes: 1. Prefix matching which is what the Trie is meant for and is the fastest at. 2. Any string matching which is still fast at 100,000 elements but probably slows down faster than prefix matching as the dataset size or maximum indexed string length grows large. If you run the example yourself you need to provide more heap space using -Xmx512M as the trade off for the quick search speed is to hold all the elements in memory. I've deployed the example application onto my website here, with 74271 indexed methods: http://rivulet.ca:8080/datatable-autocomplete-examples-1.4-SNAPSHOT/ I plan on having the datatable-autocomplete module available through maven but currently you have to check it out from subversion: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/datatable-autocomplete-parent Issues can be created here: http://wicketstuff.org/jira/browse/WSDTA I hope this will be useful to others, Regards, Mike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: not addding componet in case of error
Or just set visibility based on error
On Saturday, December 12, 2009, vineet semwal
wrote:
> add empty webmarkupcontainers as your components,if no error,replace the
> containers with your components
> else
> you don't need to replace.
>
>
> On Sat, Dec 12, 2009 at 8:02 AM, Swarnim Ranjitkar
> wrote:
>
>>
>> I have a case where I check some error condition at the beginning of the
>> code. If there is error I just want to display error message so
>> basically it is
>> if (error == true){
>> display message
>> } else {
>> //render regular page
>> add(component1)
>> add(compnent2)
>> }
>>
>> if there is error I don't have any data to generate my component. Is there
>> a clean way to do this. I'm getting
>> Unable to find component with id 'chart1image' exception. Appreciate your
>> feedback
>> thank you
>>
>>
>>
>
>
>
>
> --
> regards,
> Vineet Semwal
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [announce] Wicket 1.4.4
great! "los re banco muchachos" is what we would say in argentina :) NM On Fri, Dec 11, 2009 at 3:35 PM, Igor Vaynberg wrote: > and now with a working changelog link: > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310561&fixfor=12314323&sorter/field=priority&sorter/order=DESC > > -igor > > On Fri, Dec 11, 2009 at 10:16 AM, Igor Vaynberg > wrote: > > The Apache Wicket project is proud to announce the fourth maintenance > > release of Apache Wicket 1.4. > > > > Download Apache Wicket 1.4 > > -- > > You can download the release here: > > http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 > > > > Or use this in your Maven pom's to upgrade to the new version: > > > > > > org.apache.wicket > > wicket > > 1.4.4 > > > > > > Changes > > - > > A complete list of changes can be found here: > > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?fixfor=12314323 > > > > We thank you for your patience and support. > > > > -The Wicket Team > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: SpringWicketTester code (tested with Wicket 1.4 and spring-wicket)
Does this handle transactions (e.g. rolls transactions back at the end of a
test method) like the test runners provided by Spring?
Loritsch, Berin C. wrote:
>
> import javax.servlet.ServletContext;
>
> import org.apache.wicket.protocol.http.MockServletContext;
> import org.apache.wicket.protocol.http.WebApplication;
> import org.apache.wicket.util.tester.WicketTester;
> import org.springframework.web.context.WebApplicationContext;
> import org.springframework.web.context.support.XmlWebApplicationContext;
>
> /**
> * Spring enabled WicketTester allows a user to test applications that
> have
> * been wired using the SpringComponentInjector. This subclass of the
> * WicketTester sets up the spring web context, which is normally set up
> by
> * the org.springframework.web.context.ContextLoaderListener class.
> */
> public class SpringWicketTester extends WicketTester {
> /**
>* The Spring web application context
>*/
> private XmlWebApplicationContext spring;
>
> /**
>* Instantiate the WicketTester with your application and a set
> of URLs
>* to find the Spring XML configuration files. Ex:
>*
>*
>* new SpringWicketTester(new MyApp(),
> "classpath:application.xml",
>*
> "classpath:application-test.xml");
>*
>*
>* @param app Your Wicket web application
>* @param springConfigURLs The set of URLs for the
> configuration files.
>*/
> public SpringWicketTester(WebApplication app, String...
> springConfigURLs) {
> this(app, null, springConfigURLs);
> }
>
>
> /**
>* Instantiate the WicketTester with your application and a set
> of URLs
>* to find the Spring XML configuration files. Ex:
>*
>*
>* new SpringWicketTester(new MyApp(), "myapp",
>*
> "classpath:application.xml",
>*
> "classpath:application-test.xml");
>*
>*
>* @param app Your Wicket web application
>* @param context The base url for the application
>* @param springConfigURLs The set of URLs for the
> configuration files.
>*/
> public SpringWicketTester(WebApplication app, String context,
> String... springConfigURLs) {
> super(app, context);
>
> reconfigure(springConfigURLs);
> }
>
> /**
>* Reconfigure the tester with new spring configuration files.
> This method
>* also calls the Spring refresh method to force
> the files to
>* load.
>*
>* @param springConfigURLs The set of URLs for the
> configuration files.
>*/
> public void reconfigure(String... springConfigURLs) {
> getSpringContext().setConfigLocations(springConfigURLs);
> getSpringContext().refresh();
> }
>
> /**
>* Create the new ServletContext that will be used with this
> test session.
>* This method configures the spring web context to be included
> in your
>* Servlet context. It's the magic that makes everything happy.
>*
>* @param path the root context path for URLs
>*
>* @return a configured ServletContext
>*/
> @Override
> public ServletContext newServletContext(final String path) {
> ServletContext context = new
> MockServletContext(getApplication(), path);
> getSpringContext().setServletContext(context);
>
> context.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_
> ATTRIBUTE, spring);
> return context;
> }
>
> /**
>* Lazy loader for the creating the SpringContext. Required to
> work around
>* the initialization in the constructor.
>*
>* @return the single web application context for this tester
>*/
> private XmlWebApplicationContext getSpringContext() {
> if(null == spring) {
> spring = new XmlWebApplicationContext();
> }
>
> return spring;
> }
> }
>
>
--
View this message in context:
http://old.nabble.com/SpringWicketTester-code-%28tested-with-Wicket-1.4-and-spring-wicket%29-tp26326536p26769106.html
Sent from the Wicket - User 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: enclosure changes in 1.4.4
What about RFE for
??
**
Martin
2009/12/13 Anton Veretennikov :
> Consistency is one of wicket's strengths. My tiny vote for 1.4.4
>
> -- Tony
>
> On Sun, Dec 13, 2009 at 3:35 PM, Girts Ziemelis
> wrote:
>> I also liked the behaviour - it made the code shorter, as I did not have to
>> mirror the component tree in both then and else branches.
>> I guess it is not a big deal, except for the testing headaches - this breaks
>> the code at runtime :(
>> I now, i know - I should have test cases covering all branches in the form
>> :(
>>
>>
>> On 12/13/2009 08:14 AM, Douglas Ferguson wrote:
>>>
>>> I did find the behavior handy, but it is easy to work around.
>>>
>>> D/
>>>
>>> On Dec 12, 2009, at 11:12 PM, Igor Vaynberg wrote:
>>>
>>>
i think you guys misunderstand.
i believe what we are talking about here is the requirement for
presence of components *other* then the component specified by
enclosure's child attribute.
essentially if i do this:
add(new webmarkupcontainer("container").setvisible(false));
and have this in my markup:
wicket will not throw an error even though i never added the "foo"
component to my component hierarchy because as soon as it determins
that the container div is not visible it will skip over until the
closing tag.
the enclosures, however, as of 1.4.4 *will* throw an error for *any*
missing child declared inside enclosure's markup *even though* the
enclosure has been determined as hidden.
hope this clears it up somewhat
-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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
SV: enclosure changes in 1.4.4
> Consistency is one of wicket's strengths. My tiny vote for 1.4.4 > > -- Tony +1 I never interpreted wicket:enclosure (as documented) as allowing the child attribute to reference a component anywhere else than inside the enclosure. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: enclosure changes in 1.4.4
Consistency is one of wicket's strengths. My tiny vote for 1.4.4
-- Tony
On Sun, Dec 13, 2009 at 3:35 PM, Girts Ziemelis
wrote:
> I also liked the behaviour - it made the code shorter, as I did not have to
> mirror the component tree in both then and else branches.
> I guess it is not a big deal, except for the testing headaches - this breaks
> the code at runtime :(
> I now, i know - I should have test cases covering all branches in the form
> :(
>
>
> On 12/13/2009 08:14 AM, Douglas Ferguson wrote:
>>
>> I did find the behavior handy, but it is easy to work around.
>>
>> D/
>>
>> On Dec 12, 2009, at 11:12 PM, Igor Vaynberg wrote:
>>
>>
>>>
>>> i think you guys misunderstand.
>>>
>>> i believe what we are talking about here is the requirement for
>>> presence of components *other* then the component specified by
>>> enclosure's child attribute.
>>>
>>> essentially if i do this:
>>>
>>> add(new webmarkupcontainer("container").setvisible(false));
>>> and have this in my markup:
>>>
>>>
>>> wicket will not throw an error even though i never added the "foo"
>>> component to my component hierarchy because as soon as it determins
>>> that the container div is not visible it will skip over until the
>>> closing tag.
>>>
>>> the enclosures, however, as of 1.4.4 *will* throw an error for *any*
>>> missing child declared inside enclosure's markup *even though* the
>>> enclosure has been determined as hidden.
>>>
>>> hope this clears it up somewhat
>>>
>>> -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
URL Rewriting in Wicket
Hello, I would like to do a simple URL rewriting in my application: All requests containing a given path (e.g., a "/x/...") should be filtered and redirected accordingly. In other words, for a request to http://www.example.com/x/something I want to do a database lookup based on the value of "something" and then redirect the user to the appropriate wicket page. What is the recommended way to do this in wicket? Make a hook into the WebApplication.newRequestCycle() method? thanks for your help, andr
Re: SpringWicketTester code (tested with Wicket 1.4 and spring-wicket)
Great post! I had difficulties getting the wicket tester up and running with my Spring-enabled app but your class worked like a charm. Wouldn't it be a good idea to contribute that code to the wicket-spring subproject? best regards, Peter -- View this message in context: http://old.nabble.com/SpringWicketTester-code-%28tested-with-Wicket-1.4-and-spring-wicket%29-tp26326536p26765130.html Sent from the Wicket - User 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: enclosure changes in 1.4.4
I also liked the behaviour - it made the code shorter, as I did not have
to mirror the component tree in both then and else branches.
I guess it is not a big deal, except for the testing headaches - this
breaks the code at runtime :(
I now, i know - I should have test cases covering all branches in the
form :(
On 12/13/2009 08:14 AM, Douglas Ferguson wrote:
I did find the behavior handy, but it is easy to work around.
D/
On Dec 12, 2009, at 11:12 PM, Igor Vaynberg wrote:
i think you guys misunderstand.
i believe what we are talking about here is the requirement for
presence of components *other* then the component specified by
enclosure's child attribute.
essentially if i do this:
add(new webmarkupcontainer("container").setvisible(false));
and have this in my markup:
wicket will not throw an error even though i never added the "foo"
component to my component hierarchy because as soon as it determins
that the container div is not visible it will skip over until the
closing tag.
the enclosures, however, as of 1.4.4 *will* throw an error for *any*
missing child declared inside enclosure's markup *even though* the
enclosure has been determined as hidden.
hope this clears it up somewhat
-igor
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
