Inheritance at the panel level
I know markup inheritance (wicket:child/wicket:child) works at the Page level but does wicket also support markup inheritance at the in Panel level? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sanity check. Can't inject DAO
Pardon my possible ignorance but didn't the need to use DAOs evaporate once transparent persistence (eg., Hibernate, JDO) hit the streets a few years back? I always thought the DAO architecture was what we used in the old days in the absence of mature transparent persistence solutions when we had a DAO per persistent class to help with the persistence of that class. Now that persistence is effectively transparent (using Hibernate, JPOX etc.,) aren't they now redundant? > >>> Have you tried with naming the dao to be injected explicitly? i.e. > >>> > >>> @SpringBean (name="ProtocolDAO") > >>> private ProtocolDAO dao; > >> > >> Interesting. That seems to get me closer... > >> > >> org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean > >> named 'ProtocolDAO' must be of type > >> [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of type > >> [$Proxy30] > >> > >> Checking google... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Inheritance at the panel level
Great news, thanks! > Yes, all components support markup inheritance. Give it a try! > > On Thu, May 29, 2008 at 9:14 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > I know markup inheritance (wicket:child/wicket:child) works at the Page > > level but does wicket also support markup inheritance at the in Panel > > level? > > > > - > > 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: Sanity check. Can't inject DAO
Oh ok, it's probably just a terminology issue then. We use JDO and hence the PersistenceManager is our equivalent to the others you speak of. In the past DAOs were always a beast that had to be dealt with explicitly to store and retrieve objects. The Hibernate Session, JDO PersistenceManager etc., are a lot less 'manual' with automatic 'load on demand' and update of dirty objects and so I never associated them with the old fashioned DAOs we used to create. We also use the "Exposed POJO Domain Model" pattern with its 'repositories' (for locating objects) and 'services' (for making significant model changes according to embedded business rules) which allows us to write code that can be easily ported to any transparent persistence provider and it manages all the dependency injection in a very light weight manner in simple Java rather than a 'sea of XML' which really turned me off Spring. > the need for dao per entity class has gone away with transparent > persistence, however there is still a "dao" that is a hibenate > session, jpa entitymanager, cayenne context, or whatever. > > also, some people still use dao to store finder/batch update methods. > > -igor > > On Thu, May 29, 2008 at 6:19 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > Pardon my possible ignorance but didn't the need to use DAOs evaporate > > once transparent persistence (eg., Hibernate, JDO) hit the streets a few > > years back? > > > > I always thought the DAO architecture was what we used in the old days > > in the absence of mature transparent persistence solutions when we had a > > DAO per persistent class to help with the persistence of that class. Now > > that persistence is effectively transparent (using Hibernate, JPOX > > etc.,) aren't they now redundant? > > > >> >>> Have you tried with naming the dao to be injected explicitly? i.e. > >> >>> > >> >>> @SpringBean (name="ProtocolDAO") > >> >>> private ProtocolDAO dao; > >> >> > >> >> Interesting. That seems to get me closer... > >> >> > >> >> org.springframework.beans.factory.BeanNotOfRequiredTypeException: > > Bean > >> >> named 'ProtocolDAO' must be of type > >> >> [com.vzbi.ncs.argfrp.jpa.netconf.ProtocolDAO], but was actually of > > type > >> >> [$Proxy30] > >> >> > >> >> Checking google... > > > > - > > 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]
Pickup up new markup without restarting webapp
Is there a wicket mode I can configure in which new markup (eg., new markup variations) can be picked up at run time without restarting the app? In our app we can create/generate new markup at runtime. We don't want to have to force a bounce of the web app for wicket to 'see' this new markup. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple bookmarks to same page class - possible?
Is it possible to route multiple bookmarks using mountBookmarkablePage to the same page class? Also, is it possible for the page to ask what it's bookmark (or URL) is? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pickup up new markup without restarting webapp
> Chris, > > Generating static markup files is not really the "Wicket way" of doing > things. Couldn't you just use multiple panels and dynamically add/replace > as needed ...create-dynamic-markup-hierarchies-using-panels.html? The scope of different markup we use involves massive changes to the whole page, not just a few panels so this solution won't work well for us. > Or maybe variations will work for you (see > http://cwiki.apache.org/WICKET/multiple-markups-per-page.html)? We do use variations - therein lies the problem: A new variation is generated to the file system by the web app but when wicket tries to render the page using that new variation the variation's markup will be ignored until after we bounce the web app. > If neither of these fits th bill, you could try using a > ReloadingWicketFilter: > http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/proto co > l/http/ReloadingWicketFilter.html Does this solution cause a reloading of the entire web app when a new markup is detected? If so, ouch! The markup files can be regenerated quite frequently and we can't afford to bounce the whole web app each time. Is there an interface used to provide the markup to wicket for which we can provide our own implementation and do the loading and caching of markup and checking for new markup ourselves? > > Cheers, > Jay > On Thu, Feb 28, 2008 at 2:40 PM, Chris Colman > <[EMAIL PROTECTED]> > wrote: > > > Is there a wicket mode I can configure in which new markup (eg., new > > markup variations) can be picked up at run time without restarting the > > app? > > > > In our app we can create/generate new markup at runtime. We don't want > > to have to force a bounce of the web app for wicket to 'see' this new > > markup. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > Computer Science: solving today's problems tomorrow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pickup up new markup without restarting webapp
I wonder which of the methods I need to override: protected IMarkupLoader getMarkupLoader() In case there is a need In my app I already override ResourceStreamLocator to tell wicket where to find the markup (as it can't be in the web app itself for our app). Are there any other methods in that class which would be appropriate for overriding? > Chris, > > Have you looked at subclassing MarkupCache? I'm just a Wicket user so one > of > the devs might want to weigh in but that is where I would start looking. > > http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/marku p/ > MarkupCache.html > > Cheers, > Jay > > On Thu, Feb 28, 2008 at 4:01 PM, Chris Colman > <[EMAIL PROTECTED]> > wrote: > > > > Chris, > > > > > > Generating static markup files is not really the "Wicket way" of doing > > > things. Couldn't you just use multiple panels and dynamically > > add/replace > > > as needed ...create-dynamic-markup-hierarchies-using-panels.html? > > > > The scope of different markup we use involves massive changes to the > > whole page, not just a few panels so this solution won't work well for > > us. > > > > > Or maybe variations will work for you (see > > > http://cwiki.apache.org/WICKET/multiple-markups-per-page.html)? > > > > We do use variations - therein lies the problem: A new variation is > > generated to the file system by the web app but when wicket tries to > > render the page using that new variation the variation's markup will be > > ignored until after we bounce the web app. > > > > > If neither of these fits th bill, you could try using a > > > ReloadingWicketFilter: > > > > > > http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/proto ttp://people.apache.org/%7Etobrien/wicket/apidocs/org/apache/wicket/prot o> > > co > > > l/http/ReloadingWicketFilter.html > > > > Does this solution cause a reloading of the entire web app when a new > > markup is detected? If so, ouch! The markup files can be regenerated > > quite frequently and we can't afford to bounce the whole web app each > > time. > > > > Is there an interface used to provide the markup to wicket for which we > > can provide our own implementation and do the loading and caching of > > markup and checking for new markup ourselves? > > > > > > > > Cheers, > > > Jay > > > On Thu, Feb 28, 2008 at 2:40 PM, Chris Colman > > > <[EMAIL PROTECTED]> > > > wrote: > > > > > > > Is there a wicket mode I can configure in which new markup (eg., new > > > > markup variations) can be picked up at run time without restarting > > the > > > > app? > > > > > > > > In our app we can create/generate new markup at runtime. We don't > > want > > > > to have to force a bounce of the web app for wicket to 'see' this > > new > > > > markup. > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > > > > Computer Science: solving today's problems tomorrow. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > Computer Science: solving today's problems tomorrow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pickup up new markup without restarting webapp
The interesting thing is that a bounce of the app reads the new variants without a problem. This seems to indicate to me that there must be some initial 'markup discovery' operation when wicket starts up and only those markup files found during that discovery operation can be loaded, ever. It is interesting that in development mode changed markups will be detected and the latest markup will be used - this is a development mode feature we definitely need in production so that we can change markup without requiring an app bounce. If wicket can detect changed markup when in development mode there must be some 'flag' or 'switch' that we can turn on to tell wicket to detect new markup as well. How hard would this be to add? Is not looking for new markups a performance based design decision? It's not like wicket would have to poll the markup directories constantly - it only needs to check for the existence of a markup file when requested and only if it's not already found in the cache so a check of the file system would only occur the very first time a new page was requested because then it would not exist in the cache. Further requests would merely return the cached version. I would think that this would have negligible affect on performance. > -Original Message- > From: Jay Hogan [mailto:[EMAIL PROTECTED] > Sent: Friday, 29 February 2008 8:23 AM > To: users@wicket.apache.org > Subject: Re: Pickup up new markup without restarting webapp > > Chris, > > Have you looked at subclassing MarkupCache? I'm just a Wicket user so one > of > the devs might want to weigh in but that is where I would start looking. > > http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/marku p/ > MarkupCache.html > > Cheers, > Jay > > On Thu, Feb 28, 2008 at 4:01 PM, Chris Colman > <[EMAIL PROTECTED]> > wrote: > > > > Chris, > > > > > > Generating static markup files is not really the "Wicket way" of doing > > > things. Couldn't you just use multiple panels and dynamically > > add/replace > > > as needed ...create-dynamic-markup-hierarchies-using-panels.html? > > > > The scope of different markup we use involves massive changes to the > > whole page, not just a few panels so this solution won't work well for > > us. > > > > > Or maybe variations will work for you (see > > > http://cwiki.apache.org/WICKET/multiple-markups-per-page.html)? > > > > We do use variations - therein lies the problem: A new variation is > > generated to the file system by the web app but when wicket tries to > > render the page using that new variation the variation's markup will be > > ignored until after we bounce the web app. > > > > > If neither of these fits th bill, you could try using a > > > ReloadingWicketFilter: > > > > > > http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/proto ttp://people.apache.org/%7Etobrien/wicket/apidocs/org/apache/wicket/prot o> > > co > > > l/http/ReloadingWicketFilter.html > > > > Does this solution cause a reloading of the entire web app when a new > > markup is detected? If so, ouch! The markup files can be regenerated > > quite frequently and we can't afford to bounce the whole web app each > > time. > > > > Is there an interface used to provide the markup to wicket for which we > > can provide our own implementation and do the loading and caching of > > markup and checking for new markup ourselves? > > > > > > > > Cheers, > > > Jay > > > On Thu, Feb 28, 2008 at 2:40 PM, Chris Colman > > > <[EMAIL PROTECTED]> > > > wrote: > > > > > > > Is there a wicket mode I can configure in which new markup (eg., new > > > > markup variations) can be picked up at run time without restarting > > the > > > > app? > > > > > > > > In our app we can create/generate new markup at runtime. We don't > > want > > > > to have to force a bounce of the web app for wicket to 'see' this > > new > > > > markup. > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > > > > Computer Science: solving today's problems tomorrow. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > Computer Science: solving today's problems tomorrow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pickup up new markup without restarting webapp
> Chris, > > I'm not that familiar with the inner workings of the API but based on the > description in the Javadoc, I think you are going to need to provide a > custom implementation of IMarkupCache. > > If you are looking for a simpler solution, you could enter an RFE for new > property on iMarkupSettings that replicates the DEV mode markup reload > functionality. Yeah, that would be excellent - a setting that causes the markup loader to check for the existence of a piece of markup (possibly a variant) in the file system if it can not be found in the cache. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Location of wicket-ajax.js
When using AJAX with wicket where are the instructions on where and how to make the .js available to the browser? Eg., resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js Do we have to create a directory under project/web called resources/org.apache.wicket.ajax.WicketAjaxReference ? into which we copy the .js? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Location of wicket-ajax.js
Do we have to explicitly unpack the .js files from the wicket-1.3.x.jar and move them into that directory or should it find them while resident in the wicket jar ? > no, resources is a path that is owned by wicket resources. so what > that url tells wicket is to look for wicket-ajax.js under > classes/org/apache/wicket/ajax > > -igor > > > On Thu, Feb 28, 2008 at 9:47 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > When using AJAX with wicket where are the instructions on where and how > > to make the .js available to the browser? > > > > Eg., resources/org.apache.wicket.ajax.WicketAjaxReference/wicket- > ajax.js > > > > Do we have to create a directory under project/web called > > resources/org.apache.wicket.ajax.WicketAjaxReference ? into which we > > copy the .js? > > > > > > - > > 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: Location of wicket-ajax.js
Problem found: Was a problem with
RE: Location of wicket-ajax.js
Using 1.3.0 - maybe I should try 1.3.1 > -Original Message- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Friday, 29 February 2008 6:29 PM > To: users@wicket.apache.org > Subject: Re: Location of wicket-ajax.js > > this should happen automatically, please file a bug report > > -igor > > > On Thu, Feb 28, 2008 at 11:26 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > Problem found: Was a problem with
RE: Location of wicket-ajax.js
The class derives, ultimately, from the WebPage class. Should I try deriving it from some other wicket base class as a workaround? > there are no conditions, these things are pushed to wicket by > invocations on iheadercontributor's iheaderresponse interface by all > interested components/behaviors. i guess wicket ignores these if the > page is stateless, which woud be a bug... > > -igor > > On Fri, Feb 29, 2008 at 12:50 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > I've tried 1.3.1 and still no luck in getting wicket to inject the > > appropriate
RE: Location of wicket-ajax.js
I've tried 1.3.1 and still no luck in getting wicket to inject the appropriate
RE: Location of wicket-ajax.js
I tried that by adding a TextField - still no joy. > no. webpage is the correct choice. as a workaround you can make the > page stateful > > -igor > > > On Fri, Feb 29, 2008 at 1:04 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > The class derives, ultimately, from the WebPage class. Should I try > > deriving it from some other wicket base class as a workaround? > > > > > > > > > there are no conditions, these things are pushed to wicket by > > > invocations on iheadercontributor's iheaderresponse interface by all > > > interested components/behaviors. i guess wicket ignores these if the > > > page is stateless, which woud be a bug... > > > > > > -igor > > > > > > On Fri, Feb 29, 2008 at 12:50 PM, Chris Colman > > > <[EMAIL PROTECTED]> wrote: > > > > I've tried 1.3.1 and still no luck in getting wicket to inject the > > > > appropriate
RE: Location of wicket-ajax.js
How do I force a page to be stateful? > I tried that by adding a TextField - still no joy. > > > no. webpage is the correct choice. as a workaround you can make the > > page stateful > > > > -igor > > > > > > On Fri, Feb 29, 2008 at 1:04 PM, Chris Colman > > <[EMAIL PROTECTED]> wrote: > > > The class derives, ultimately, from the WebPage class. Should I try > > > deriving it from some other wicket base class as a workaround? > > > > > > > > > > > > > there are no conditions, these things are pushed to wicket by > > > > invocations on iheadercontributor's iheaderresponse interface by > all > > > > interested components/behaviors. i guess wicket ignores these if > the > > > > page is stateless, which woud be a bug... > > > > > > > > -igor > > > > > > > > On Fri, Feb 29, 2008 at 12:50 PM, Chris Colman > > > > <[EMAIL PROTECTED]> wrote: > > > > > I've tried 1.3.1 and still no luck in getting wicket to inject > the > > > > > appropriate
RE: Location of wicket-ajax.js
> I kinda miss the point of this entire thread? What exactly doesn't > work? Are you getting no javascript references written to your > section? How did you map the WicketFilter? Whoooh! I think you might have found the problem for us. We're still mapping via the WicketServlet not the filter. Maybe that's a wicket 1.2.x legacy that we neglected to migrate when we switched to 1.3.x. We already have an exPOJO filter auto handling persistence for us so I guess we now have to chain that filter with the wicket filter. I wonder how we do that... MyServer org.apache.wicket.protocol.http.WicketServlet applicationClassName com.sas.av.ui.wicket.MyApp 1 MyServer /content/* > > > -Matej > > On Sat, Mar 1, 2008 at 7:19 AM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > How do I force a page to be stateful? > > > > > > > > > I tried that by adding a TextField - still no joy. > > > > > > > no. webpage is the correct choice. as a workaround you can make the > > > > page stateful > > > > > > > > -igor > > > > > > > > > > > > On Fri, Feb 29, 2008 at 1:04 PM, Chris Colman > > > > <[EMAIL PROTECTED]> wrote: > > > > > The class derives, ultimately, from the WebPage class. Should I > > try > > > > > deriving it from some other wicket base class as a workaround? > > > > > > > > > > > > > > > > > > > > > there are no conditions, these things are pushed to wicket by > > > > > > invocations on iheadercontributor's iheaderresponse interface > > by > > > all > > > > > > interested components/behaviors. i guess wicket ignores these > > if > > > the > > > > > > page is stateless, which woud be a bug... > > > > > > > > > > > > -igor > > > > > > > > > > > > On Fri, Feb 29, 2008 at 12:50 PM, Chris Colman > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > I've tried 1.3.1 and still no luck in getting wicket to > > inject > > > the > > > > > > > appropriate
RE: Markup Reloading
I have a similar problem but it's to do with creating new markup variations - each new one I add requires a server restart for it to be detected. Apparently customers don't like that for some strange reason =) I think your problem is easily solved - you just have to run you production server in development mode but even in development mode my problem is not solved. > Hi Guys, > > I've noticed that everytime I want to change something in my markup I > would > need to restart > the server as the changes don't take effect immediately. Is there anything > I > can do to avoid this behavior? > I'm trying to adjust my css and i'm spending more time restarting the > server... > > Thanks > Carlo > -- > View this message in context: http://www.nabble.com/Markup-Reloading- > tp15779009p15779009.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: Markup Reloading
> On Sat, Mar 1, 2008 at 3:10 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > I have a similar problem but it's to do with creating new markup > > variations - each new one I add requires a server restart for it to be > > detected. Apparently customers don't like that for some strange reason > > =) > > we cache the fact that variation does not exist, otherwise we would > have to perform the expensive search every time. your problem can be > solved by clearing the markup cache after you deploy new variations - > that should work even in production mode servers. > > -igor Arh, now I understand the mechanism. The cache doesn't only cache existing markup variations it also caches tokens that say, "this markup variation does not exist". So it's caching non existent entities ... which sounds very strange at first but I can understand why that makes sense for performance reasons. How would one go about clearing this cache? Is it possible to just clear a specific page's cache of a non existent variant or it a "clear entire" cache a better approach. Clearing the entire cache seems easier and is a 100% improvement over rebouncing the entire web app. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Markup Reloading
Thanks, I'll give that a go. > i think it is: > > getapplication().getmarkupsettings().getmarkupcache().clear(); which > will clear the entire cache. > > there is also a jmx hook. > > -igor > > > On Sat, Mar 1, 2008 at 3:25 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > > On Sat, Mar 1, 2008 at 3:10 PM, Chris Colman > > > <[EMAIL PROTECTED]> wrote: > > > > I have a similar problem but it's to do with creating new markup > > > > variations - each new one I add requires a server restart for it > to > > be > > > > detected. Apparently customers don't like that for some strange > > reason > > > > =) > > > > > > we cache the fact that variation does not exist, otherwise we would > > > have to perform the expensive search every time. your problem can be > > > solved by clearing the markup cache after you deploy new variations - > > > that should work even in production mode servers. > > > > > > -igor > > > > Arh, now I understand the mechanism. The cache doesn't only cache > > existing markup variations it also caches tokens that say, "this markup > > variation does not exist". So it's caching non existent entities ... > > which sounds very strange at first but I can understand why that makes > > sense for performance reasons. > > > > How would one go about clearing this cache? Is it possible to just > clear > > a specific page's cache of a non existent variant or it a "clear > entire" > > cache a better approach. Clearing the entire cache seems easier and is > a > > 100% improvement over rebouncing the entire web app. > > > > > > > > - > > 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: Location of wicket-ajax.js
> > I kinda miss the point of this entire thread? What exactly doesn't > > work? Are you getting no javascript references written to your > > section? Correct. > > How did you map the WicketFilter? > > Whoooh! I think you might have found the problem for us. Unfortunately we still have the problem after changing over to filter instead of servlet config for wicket. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket id in component
> > first you have to realize that this is a corner case. doing > > constructor injection with actual component instances is pretty rare. > > I find myself wanting to do it quite often with side-bar panels that > contain a mix optional items I find that also - a whole branch of the page hierarchy need a particular side panel whereas another branch need a different side panel. Everything else - header, footer, menus etc., - remain pretty much constant. The solution I often find myself pining for is to be able to have more than one section in the markup that can be overridden in derived classes. (this is not the same as multiple inheritance and some wrongly assume). This makes the above very simple and very OO. This has been discussed at length on many occasions and recently spec'd out pretty accurately. Hopefully it will find its way into a not too distant release as the panel based workaround isn't as elegant, nor efficiently coded as a pure OO approach. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wicke quickstart
Back in 1.2.4 days there was a fully self contained wicket quickstart zip that contained everything needed to build and deploy some sample wicket apps to a servlet container. Is there any such zip for 1.3.x? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: wicke quickstart
I found the wicket-examples directory in the wicket 1.3.1 zip. We've got that building an running now. Thanks, Chris > > still there in svn, and there is also a maven > archetype...http://wicket.apache.org/quickstart.html > > -igor > > > On Sun, Mar 2, 2008 at 3:09 PM, Chris Colman > <[EMAIL PROTECTED]> wrote: > > Back in 1.2.4 days there was a fully self contained wicket quickstart > > zip that contained everything needed to build and deploy some sample > > wicket apps to a servlet container. > > > > Is there any such zip for 1.3.x? > > > > - > > 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]
maven surefile issue
We store markup in a separate external directory to the source code and it works all well compiling under ant but we're now compiling wicket-examples using maven and we've moved the markup into an external directory and maven now complains that the markup files can't be found. Is there a way to turn off that surefire thing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven surefile issue
> Or don't store the markup in an external directory. It will make > building reusable components a lot harder. ...and make it mandatory to bounce the enterprise web app whenever a designer makes a change to the markup which is not an option for this app unfortunately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: how do you craft your enterprise class designs? (MVP or plain Wicket?)
> Personally, I like to approach everything "enterprisey" by using services > > which can be split into different areas of functionality. That sounds very similar to the highly productive Exposed Domain Model POJOs pattern as described in "POJOs in Action". We've used that pattern very successfully on two major enterprise projects that use transparent persistence (JDO but Hibernate works almost as well). In fact we ended up creating an open source framework (free for commercial and open source use) that helps implement the Exposed Domain Model POJOs pattern in a project called exPOJO available at http://www.expojo.com It does all the necessary dependency injection and also provides JDO and Hibernate wrappers so your POJOs can stay 'persistence engine agnostic'. It's very small, lightweight and easy to use - a bit like Spring was before it tried to do everything. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Parameters as /param-name/param-value over traditional query strings
I've been using wicket for quite some time now and I just have a question regarding the reason why wicket parameters are sent as a sequence of /param-name/param-value/ pairs instead of the traditional ?param-name=param-value& etc., query strings. Was the reason that it was believed that /p/v pairs are more search engine friendly that traditional query strings? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing to session scope attribute
I need to store some data on a per session basis. What's the best approach in a wicket environment? 1. Should I create my own session factory and create a custom session class that stores the data as an attribute? OR 2. Go the old fashioned route and retrieve the J2?E HttpSession and store it in that using setAttribute(name, object); BTW how do we get access to the J2?E session in Wicket? OR 3. Something else I haven't thought of yet... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket consulting/contracting/outsourcing
> >> Hi, > >> > >> Can anyone provide me with pointers to individuals or companies > providing > >> Wicket consulting/contracting or outsourced personnel? > >> We can provide those services but we're based in Sydney, Australia. Maybe that's not such a problem with us all living together in this global village these days. We've worked with a Boston company before back in 2000. These days of Skype and video conferencing would make that even easier and less expensive. Regards, Chris Colman Technical Directory http://stepaheadsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ExternalLink documentation enhancement
For the first time I had to provide an external link to the outside from a Wicket app - heh, it happens sometimes ;) One thing I discovered that I couldn't find documented in the ExternalLink class was that you need to put a 'http://' prefix prior to the URL so that the URL gets formed properly - ie., not appended to the current wicket page's URL. I would have thought that an external link without any protocol prefix should always default to an absolute link to an http:// page and not a relative link from the current page. Being an external link, by definition, it could never be a relative link from the current page I wouldn't think. Perhaps if the documentation could be enhanced to mention the need to add the protocol prefix (eg 'http://') it might help others who come across this issue. Thanks again for the world's best Object Oriented, Component Based UI framework! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best approach for list items: discrete markup or panels?
I have a number of pages that display a list of items and am wondering about the best approach to implementing them in Wicket. To date I have created a single panel that contains the list and the markup for that panel holds the discrete markup elements for the fields in each item of the list. Another approach could be to create an individual panel that is responsible for providing the data for the items in the list. Then the list page markup just has a reference to that panel instead of holding the discrete item fields itself. I'm just wondering if anyone has used the later approach and with what success. It probably means there is a little bit of extra work up front to create the list panel markup and its class but then I end up with a reusable panel that I would easily be dropped into other pages as required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Presented Wicket to my Company...
> Well here's our story, if it helps you. Here's ours as well: Wicket (+some Echo2) + "exposed POJO model" managed by Javelin + JPOX for the ORM. Having come from a JSP/Struts + home grown ORMish kind of framework using proxy/reflection implementation (yuck) this new set of tools is ***ken awesome and orders of magnitude more productive. Wicket -- We sit our wicket pages/forms straight on top of our domain model objects (exposed POJO model pattern) and yes, all the DTO lovers out there will cry "heretic" and they are most welcome to continue the 'self flagellation' that becomes of the extra DTO layer if they want. But for our scenario: we've never had to make a change to a model object that we haven't had to reflect in the user interface anyway so the argument that "the DTO layer shields the user interface from model changes" is 99.9% of the time completely bogus. I'm also assuming no one is still using DAOs either - they're completely redundant in a 'transparent persistence' world. We looked around at most of the Java UI frameworks (and you probably know that there's a lot of them). The two best that we liked that suited our needs were Wicket and Tapestry as they both had similar goals but Wicket won hands done on its approach and the quality of its implementation. Most of our pages need to be bookmarkable so that cut out frameworks like Echo2 for those pages but for some of the pages that don't need to be bookmarkable or indexed by search engines we use Echo2 for its pure Java approach to Ajax. Persistence --- The new 'ASM' byte code enhancer plus new 'enhance on the demand' feature of JPOX 1.2 (http://www.jpox.org) makes the transparent persistence of our POJO model a nirvana that has to be seen to be believed. Javelin (http://stepaheadsoftware.com/products/javelin/javelin.htm) automatically creates and updates all ORM metadata for us as we add to and change the domain model. Exposed POJO Pattern/Dependency Injection Framework --- We use lightweight exPOJO (http://expojo.com) for dependency injection and a really easy to learn implementation of the "exposed POJO model' pattern. It also provides an abstraction layer for transparent persistence engines so we can perform performance analysis of our app under JDO (JPOX) or Hibernate (it's easy to implement plug-ins for others). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Making ExternalLink invisible: test for what?
I have content that I render that may or may not have a URL associated
with it. I don't want to display anything if the URL is blank.
I use ExternalLink for the URLs. As I place a reference to the link in
my markup I need to instantiate an ExternalLink object in the
corresponding page/panel classes using an anonymous class with
overridden isVisible method:
add(
new ExternalLink("externallink",
"http://"; + content.getUrl(),
contentList.getUrl())
{
public boolean isVisible()
{
WHAT DO I TEST FOR HERE TO CHECK IF A NON NULL
AND
NON BLANK URL WAS PROVIDED BY
content.getUrl()? return what?;
}
}
);
I don't know what attribute or method to text to access the URL that is
configured by the ExternalLink constructor. If it's stored as a string I
basically want to go return true if (url != null && url.length() > 0)
but after handing the URL onto the contructor I don't know how to get it
back to test it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making ExternalLink invisible: test for what?
> i added the missing getters, update from trunk and you should be good.
Thanks Igor, but what are they called? getUrl(), getDisplay()?
Actually the display text is more valuable because it doesn't have the
http:// prefix so I can do a simple null or blank text whereas the URL
will always have a http:// in front of it making a trivial test not
possible.
>
> -igor
>
>
> On 10/2/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> >
> > I have content that I render that may or may not have a URL
associated
> > with it. I don't want to display anything if the URL is blank.
> >
> > I use ExternalLink for the URLs. As I place a reference to the link
in
> > my markup I need to instantiate an ExternalLink object in the
> > corresponding page/panel classes using an anonymous class with
> > overridden isVisible method:
> >
> > add(
> > new ExternalLink("externallink",
> > "http://"; + content.getUrl(),
> > contentList.getUrl())
> > {
> > public boolean isVisible()
> > {
> > WHAT DO I TEST FOR HERE TO CHECK IF A NON
NULL
> > AND
> > NON BLANK URL WAS PROVIDED BY
> > content.getUrl()? return
what?;
> > }
> > }
> > );
> >
> > I don't know what attribute or method to text to access the URL that
is
> > configured by the ExternalLink constructor. If it's stored as a
string I
> > basically want to go return true if (url != null && url.length() >
0)
> > but after handing the URL onto the contructor I don't know how to
get it
> > back to test it.
> >
> >
> >
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making ExternalLink invisible: test for what?
It's an anonymous class and I don't create an identifier for it but I
suppose I can still use:
add(new ExternalLink(..,..,..).setVisible(condition));
"Back in my day we didn't need Tapestry, or Wicket or WebObjects, or
even Servlets, or for that matter Java! We just coded in plain assembly
language. And before that we had to just type in 1's and 0's. Sometimes
we didn't even have 1's. I once had to code for an entire month,
barefoot, in the dead of winter, using just 0's... but you didn't hear
me complaining."
> -Original Message-
> From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 3 October 2007 4:36 PM
> To: users@wicket.apache.org
> Subject: Re: Making ExternalLink invisible: test for what?
>
> why not use the setVisible method?
>
> link.setVisible(StringUtils.isNotBlank(url) &&
> StringUtils.isNotBlank(...));
>
> Martijn
>
> On 10/3/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > I have content that I render that may or may not have a URL
associated
> > with it. I don't want to display anything if the URL is blank.
> >
> > I use ExternalLink for the URLs. As I place a reference to the link
in
> > my markup I need to instantiate an ExternalLink object in the
> > corresponding page/panel classes using an anonymous class with
> > overridden isVisible method:
> >
> > add(
> > new ExternalLink("externallink",
> > "http://"; + content.getUrl(),
> > contentList.getUrl())
> > {
> > public boolean isVisible()
> > {
> > WHAT DO I TEST FOR HERE TO CHECK IF A NON
NULL
> > AND
> > NON BLANK URL WAS PROVIDED BY
> > content.getUrl()? return
what?;
> > }
> > }
> > );
> >
> > I don't know what attribute or method to text to access the URL that
is
> > configured by the ExternalLink constructor. If it's stored as a
string I
> > basically want to go return true if (url != null && url.length() >
0)
> > but after handing the URL onto the contructor I don't know how to
get it
> > back to test it.
> >
> >
> >
-
> > 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-beta3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>
> -
> 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]
Wicket AJAX vs Echo AJAX
To date we've built all of our static pages in Wicket and all dynamic pages/user input forms etc., in Echo because it provides a pure Java (no need to write any JavaScript) solution to generating AJAX powered pages. The problem is when users switch from Echo pages back to Wicket pages using the browser's back button (Echo only ever has one URL for all pages so bookmarkable pages don't exist). They kind of do a "hyperspace" jump that's not very user friendly. The 'back operation' does not return them to the previous element in the path of their navigation through the Echo based portion of the application but instead returns to them to the last non echo 'page' that they were on. Echo is very cool and very fast to develop in but this one issue is causing us some grief. I'm contemplating implementing the dynamic pages in Wicket instead of Echo but have a few questions: 1. Will I have to write any Javascript to implement AJAX powered pages (I'm a Java programmer of 12 years and don't want to get down an dirty with the browser/JavaScript ever again - tried that in about 2002 and it was very painful). 2. Can AJAX powered pages be generated by Wicket in such as way that browser differences are accommodated automatically by the Wicket framework - ie., transparent to the developer? These two issues are why I chose Echo (all AJAX is done transparently to the developer) in the first place but if Wicket covers these issues satisfactorily then I could move the app to 100% Wicket. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket AJAX vs Echo AJAX
> Short answer : You do not have to write a single line of javascriptcode > to use wicket ajax behaviors. This is already done for you. Great! > Regarding browser differences, I belive they are handled(by > wicket-ajax). AFAIK in beta 4 even safari works:) Another question: How does Dojo fit into Wicket? Is it an optional extra or does Wicket 'employ' it to implement AJAX? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Preserving user input after form error
I've created a form and set up some validators on various fields. When
there is an error and the page is redisplayed showing the errors none of
the previous values that the user typed in are there.
Is there an easy way to preserve the values already entered by the user?
I tried overriding onError but it didn't seem to do get it working:
public final void onError()
{
// update model fields so the user doesn't have to type them in
again
// -> I was hoping that the next page render would get these
//values from the updated model
updateFormComponentModels();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preserving user input after form error
> thats odd, all the values should be preserved, thats our rawinput that
> all formcomponents have. Do you have a repeater/listview around your
> formcomponents.
>
Hmmm, I don't know why my form doesn't preserve it. Here's the source of
the form. Can you spot anything that I'm doing wrong?
// -[KeepHeading]-
// -[Copyright]-
/**
* (c) 2007. Step Ahead Software. All rights reserved.
*
* Source file created and managed by Javelin (TM) Step Ahead Software.
* To maintain code and model synchronization you may directly edit code
in method bodies
* and any sections starting with the 'Keep_*' marker. Make all other
changes via Javelin.
* See http://stepaheadsoftware.com for more details.
*/
package com.sas.av.ui.wicket.templates.original;
import java.lang.*;
import com.sas.av.ui.wicket.templates.original.StandardPage;
import com.sas.av.model.context.EServerContext;
// -[KeepBeforeClass]-
import com.sas.av.ui.wicket.templates.*;
import wicket.PageParameters;
import wicket.markup.html.basic.Label;
import wicket.markup.html.form.*;
import wicket.markup.html.panel.*;
import wicket.util.string.*;
import wicket.model.*;
import wicket.model.PropertyModel;
import wicket.markup.html.image.*;
import wicket.extensions.markup.html.captcha.*;
import java.lang.*;
import java.util.Random;
// -[Class]-
/**
* Information Request Page.
*
* @author Chris Colman
*/
public
class InformationRequestPage extends StandardPage
{
// -[KeepWithinClass]-
// inner class form:
public final class InformationRequestForm extends Form
{
private final InformationRequest infoRequest =
new InformationRequest();
// CAPTCHA Challenge
private String captchaValue = generateCaptchaValue();
private String captchaInput = new String("fred");
public String getCaptchaInput() {return captchaInput;}
public void setCaptchaInput(String iCaptchaInput)
{ captchaInput = iCaptchaInput; }
public String generateCaptchaValue()
{ return
Integer.toString(random.nextInt(200)+100); }
private Image captchaImage = new Image("captchaImage");
private CaptchaValidator captchaValidator;
public InformationRequestForm(final String iId)
{
super(iId);
add(new TextArea("name", new PropertyModel(infoRequest,
"name")).setRequired(true));
add(new TextArea("company", new
PropertyModel(infoRequest, "company")));
add(new TextArea("phone", new PropertyModel(infoRequest,
"phone")));
add(new TextArea("email", new PropertyModel(infoRequest,
"email")).setRequired(true));
add(new TextArea("comments", new
PropertyModel(infoRequest, "comments")));
TextField captchaField = new TextField("captcha", new
PropertyModel(this, "captchaInput"));
captchaValidator = new CaptchaValidator(captchaValue);
captchaField.add(captchaValidator);
add(captchaField);
refreshCapture();
add(captchaImage);
}
public final void onError()
{
super.onError();
// update model fields so the user doesn't have to
// type them in again
updateFormComponentModels();
refreshCapture();
}
public void refreshCapture()
{
captchaValue = generateCaptchaValue();
CaptchaImageResource captchaImageResource = new
CaptchaImageResource(captchaValue, 80, 5);
captchaImage.setImageResource(captchaImageResource);
captchaValidator.setCaptchaValue(captchaValue);
}
public final void onSubmit()
{
StringBuffer sb = new StringBuffer();
sb.append("Name " + infoRequest.getName());
PageParameters pageParameters = new PageParameters();
// set up parameters
...
setResponsePage(
InformationRequestAckPage.class,
pageParameters);
}
}
// -[Fields]-
/**
* A random object!
*/
public static transient Random random = new Random();
// -[Methods]-
/**
* Constructs the object
*/
public InformationRequestPage()
{
}
/**
*
*/
public InformationRequestPage(final PageParameters parameters)
throws StringValueConversionException
{
super(parameters);
add(new FeedbackPanel("feedback"));
add(new InformationRequestForm("informationRequest"));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preserving user input after form error
Oh yeah, I'm using Wicket 1.2.6 if that has any bearing on the situation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preserving user input after form error
> i dont know what goes wrong then for you because if i test this: > > http://wicketstuff.org/wicket12/forminput/ > > that that works fine. If you make a validation error on 1 the rest keep > there values. The only difference I can see so far is that my form page is an 'extended' page where the form component is added in mark up inside a ... form sits in here ... construct. > On 11/1/07, Chris Colman <[EMAIL PROTECTED]> wrote: > > > > Oh yeah, I'm using Wicket 1.2.6 if that has any bearing on the > > situation. > > > > - > > 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: Preserving user input after form error
> can you make sure your servlet mapping is of form /foo/* > > -igor Yes it's of that form. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> I found an excellent thread in the archives that explains this topic very > well - I swear I searched before, but obviously with the wrong keywords ;) > > http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf37 75143.html > > Multiple child/extends pairs (where you have to see such a pair as an > abstract method rather than a baseclass/subclass relationship) could help > to combine the advantages of both approaches. However, its not a feature > that would improve wickets functionality and probably not worth the effort > of implementing it ... though it might be convenient. I was the original poster of that topic (although I made a few more replies that must have ended up in a different topic). I still think that viewing the child/extends pairs as abstracts methods instead of baseclass/sublass relationships is an ultimately cool model that Wicket will eventually support one day because now I see that I'm not the only one who has seen its potential. I think the belief that the concept of multiple overridden sections in a page constitutes or is analogous to multiple inheritance is incorrect. Looking at the overridden sections as abstract methods (of which you can have many per class in Java) makes a lot of sense. It's a very clean model and totally analogous to a single inheritance model as per Java: each page or panel still only has a single page or panel (analogous to class) from which it extends. The only requirement would be that if you do choose to support multiple abstract/overridden sections you would need to provide identifiers (just like an abstract method has a name) so that the 'compiler' (wicket) knows which section in a superclass an extended class section is overriding. In pages where only one section is overridden no identifiers would be necessary and so existing markup works without change, the way it does now. I also made comment that I think the 'child/extends' nomenclature was kinda wrong sounding. It doesn't seem like a natural fit. One of the things we try to teach the OO youngsters is that inheritance is very different to a parent/child relationship. Parent/Child is an association relationship where as inheritance is more of an 'extension', 'derivation' or 'specialization'. Too late for changing this now but that's never stopped me from making a pedantic contribution in the past so why stop now? ;-) In wicket we already specify the superclass of particular page markup via the 'extends' relationship between the corresponding Java classes so there's no need to use the 'extends' term in defining the individual overridable sections in the markup. Perhaps that tag might have been called 'abstract' in the base page and 'override' in the extended page and declared like: Derived pages will supply their own side bar menu. [Abstract is a great word here because it indicates that no definition exists here - it's just declaring a placeholder - and it's perfectly analogous to the Java abstract keyword] 'Funky divider' that is common throughout the entire site goes in here Derived pages will supply their own body In the derived (extended) page markups: This is the side menu bar [A nice thing about the word override is that it is perfectly analogous to the @Override annotation in Java] 'Funky divider' comes from the base class - this section is ignored This is the side menu bar One reason that support for multiple overridden sections in a page is so useful is that it is often desirable for a whole category of pages, each with a different body section, to have a common side bar menu - that is not common throughout the entire site - just common for that range of pages - yet the 'Funky divider' IS common to the entire site and so I only want to define it in one place - in the base page. I am sure there are many other examples of its usefulness which is probably why the topic arises from the ashes like a phoenix on a regular basis. :) It would be quite feasible to add support for multiple overridden sections using the above tag names while remaining backwards compatible with existing markup by continuing to support the old tags working the way they always have. > > I hope I got it right. > Same here! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preserving user input after form error
> what servlet container are you using? i think this problem popped up > on weblogic before and was due to a combination of a weblogic bug and > the particular servlet mapping that was used. Tomcat 5.5.20 > > does the behavior happen to all form components or just some > particular one? All components don't preserve their values. > try it without that funky onerror() override. I commented out the funky onerror() override and the problem still exists. H, getting curiouser and curiouser! > > -igor > > On 11/2/07, Chris Colman <[EMAIL PROTECTED]> wrote: > > > can you make sure your servlet mapping is of form /foo/* > > > > > > -igor > > > > Yes it's of that form. > > > > > > - > > 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: Multiple tags on a single base page?
> > It would be quite feasible to add support for multiple overridden > > sections using the above tag names while remaining backwards compatible > > with existing markup by continuing to support the old > > tags working the way they always have. > > It's kind of a predictable answer, but the best way to push new ideas > forward is to supply us with a patch, so that we can discuss some > working code. The current committers don't see much in the idea, but > that doesn't mean they wouldn't want to support at least the option of > plugging this in. And hey, maybe some working code convinces us :-) > > Eelco There's nothing I would love more right now than to have to time to implement a patch to support multiple overridden sections in a wicket page but unfortunately time is one thing I don't seem to have much of these days. I can't believe 2007 is almost over - heck, where did this year go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> > There's nothing I would love more right now than to have to time to > > implement a patch to support multiple overridden sections in a wicket > > page but unfortunately time is one thing I don't seem to have much of > > these days. I can't believe 2007 is almost over - heck, where did this > > year go? > > Tell us about it :-) > > Eelco Well if time is flying by so fast that means we all must be having waay too much fun - which is probably a good thing! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preserving user input after form error
Could it be because the form page is bookmarkable?
> thats odd, all the values should be preserved, thats our rawinput that
> all formcomponents have. Do you have a repeater/listview around your
> formcomponents.
>
> On 11/1/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > I've created a form and set up some validators on various fields.
When
> > there is an error and the page is redisplayed showing the errors
none of
> > the previous values that the user typed in are there.
> >
> > Is there an easy way to preserve the values already entered by the
user?
> >
> > I tried overriding onError but it didn't seem to do get it working:
> >
> > public final void onError()
> > {
> > // update model fields so the user doesn't have to type them in
> > again
> > // -> I was hoping that the next page render would get these
> > //values from the updated model
> > updateFormComponentModels();
> > }
> >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preserving user input after form error
Ok, I'll do that. The problem probably won't happen in the quickstart
form ;)
>
> why dont you submit a quickstart and then we can figure out why its
> happening
>
> -igor
>
>
> On 11/2/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > Could it be because the form page is bookmarkable?
> >
> > > thats odd, all the values should be preserved, thats our rawinput
that
> > > all formcomponents have. Do you have a repeater/listview around
your
> > > formcomponents.
> > >
> > > On 11/1/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > > > I've created a form and set up some validators on various
fields.
> > When
> > > > there is an error and the page is redisplayed showing the errors
> > none of
> > > > the previous values that the user typed in are there.
> > > >
> > > > Is there an easy way to preserve the values already entered by
the
> > user?
> > > >
> > > > I tried overriding onError but it didn't seem to do get it
working:
> > > >
> > > > public final void onError()
> > > > {
> > > > // update model fields so the user doesn't have to type them
in
> > > > again
> > > > // -> I was hoping that the next page render would get these
> > > > //values from the updated model
> > > > updateFormComponentModels();
> > > > }
> > > >
> >
> >
-
> > 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: Preserving user input after form error
Is there a page with guidelines on making a wicket quickstart?
> why dont you submit a quickstart and then we can figure out why its
> happening
>
> -igor
>
>
> On 11/2/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > Could it be because the form page is bookmarkable?
> >
> > > thats odd, all the values should be preserved, thats our rawinput
that
> > > all formcomponents have. Do you have a repeater/listview around
your
> > > formcomponents.
> > >
> > > On 11/1/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > > > I've created a form and set up some validators on various
fields.
> > When
> > > > there is an error and the page is redisplayed showing the errors
> > none of
> > > > the previous values that the user typed in are there.
> > > >
> > > > Is there an easy way to preserve the values already entered by
the
> > user?
> > > >
> > > > I tried overriding onError but it didn't seem to do get it
working:
> > > >
> > > > public final void onError()
> > > > {
> > > > // update model fields so the user doesn't have to type them
in
> > > > again
> > > > // -> I was hoping that the next page render would get these
> > > > //values from the updated model
> > > > updateFormComponentModels();
> > > > }
> > > >
> >
> >
-
> > 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: Wicket jBPM
> I was wondering if anyone has started a Wicket project (instead of the JSF > endorsed one). I would hate to recreate the wheel if someone has already > started a similar project. Come on! Recreating the wheel is what us software engineers do best! Imagine how boring the wheel would be if we hadn't already recreated it 500 times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> if i were you i would use tags other then extend and child just so you > dont conflict. Yes Stefan, I would think that would be a better approach to use a new set of tags. It also allows you to choose more correct naming (because inheritance isn't actually a parent/child relationship so the word child just confuses the issue). Maybe wicket:abstract in the base and wicket:implements (nice - thanks to whoever suggested that) or wicket:override in the derived (extended) markup. I think using IDs up front would also be great, if not necessary, because in Java as would probably occur in wicket mark up, you can have intermediate classes that don't implement all abstract methods in a base class. Without IDs you won't know exactly which abstract method an intermediate class is implementing. This example hopefully demonstrates what I mean: Base PumpsBase - A header for all pages to do with pumps Note: no body implemented here - deferred until a more specialized class/markups: WaterPumpsBase and OilPumpsBase WaterPumpBase - Note: no header implemented here - the general PumpsBase one suffices for all pumps pages A body discussing water pumps OilPumpBase --- Note: no header implemented here - the general PumpsBase one suffices for all pumps pages A body discussing oil pumps I think the tag pairs abstract/implements flow much better from an OO perspective than child/extends. It hurts my brain way to much to think of a base class as a child. > > -igor > > > On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > > > Well, what I'd like to do is what I explained in my first post. One > would > > still have a one-one-relationship if it comes to files (Base.html, > Base.java > > - Sub.html, Sub.java). However, a Base.html might contain more than one > > . So this no longer an exact duplicate of the parent- > child > > relationship that is already specified by the java class hierarchy. It > now > > would be similar to abstract method, where the abstract class specifies > one > > or more extension points that are implemented by its subcasses ... > abstract > > methods. There isn't a restriction, that there is only one abstract > method > > per class! > > > > My proof of concept would go the probably easiest way and just link the > > first extend with the first child, the second extend with the second > child, > > the third ... you got the idea ;) At a later point it might be useful to > > link them using ids (like the names of abstract methods). > > > > You could than for instance do some hierarchies like this: > > > > BaseClass - Application base class. Navigation on top, two columns with > > wicket:extend > > SectionOneBaseClass extends BaseClass - Sub-navigation in left column > > SectionOneIndex extends SectionOneBaseClass - Navigation on top, > > sub-navigation in left column and some fancy content in right column > > > > I totally agree to anybody who argues that this is already possible by > other > > means. However, to me it seems to be the most natural and elegant way to > do > > this. > > > > As I mentioned before, I don't know Wicket's inner workings too much, so > I > > will definitely need some pointers to the right directions. > > > > My naive guess is that Wicket parses BasePage.html and looks for > > SecionOneBaseClass.html and the first as soon as it > finds a > > . The idea would know be to just add a counter to this > > call, asking for the second , rather than the first (I > doubt > > that it's really going to be that easy though). > > > > > > > > > > Bruno Borges wrote: > > > > > > Stefan, try first giving us an example of what would you like to do. > What > > > I > > > can see is that you want this: > > > > > > BasePage.html > > > > > > > > > BasePage > > > > > > This is my child: > > > > > > > > > This is my OTHER child: > > > > > > > > > > > > > > > ** Example of a child page:* > > > ChildPage.html > > > > > > > > > > > > ChildPage > > > I'm your child > > > > > > > > > > > > > > > Now, given this html, how do you see the Java code structured? What's > your > > > vision? > > > > > > On Nov 5, 2007 11:28 AM, Stefan Fußenegger <[EMAIL PROTECTED]> > > > wrote: > > > > > >> > > >> > > >> Eelco Hillenius wrote: > > >> > > > >> >> It would be quite feasible to add support for multiple overridden > > >> >> sections using the above tag names while remaining backwards > > >> compatible > > >> >> with existing markup by continuing to support the old > > > >> >> tags working the way they always have. > > >> > > > >> > It's kind of a predictable answer, but the best way to push new > ideas > > >> > forward is to supply us with a patch, so that we can discuss some > > >> > working code. The current committers don't see much in the idea, > but > > >> > that doesn't mean they wouldn't want to support at least the option > of > > >> > plugging
RE: Multiple tags on a single base page?
> thanks for that advise. > > hey chris, keep your fingers crossed. finally you could get your > wicket:abstract-wicket:override ;) That would be magic! Though I like the suggestion that someone made that we replace 'override' with implements. 'Abstract' has no implementation. 'Implements' provides the implemention - they sound nice together do you think? > > stefan > > > > igor.vaynberg wrote: > > > > if i were you i would use tags other then extend and child just so you > > dont conflict. > > > > -igor > > > > > > On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > >> > >> Well, what I'd like to do is what I explained in my first post. One > would > >> still have a one-one-relationship if it comes to files (Base.html, > >> Base.java > >> - Sub.html, Sub.java). However, a Base.html might contain more than one > >> . So this no longer an exact duplicate of the > >> parent-child > >> relationship that is already specified by the java class hierarchy. It > >> now > >> would be similar to abstract method, where the abstract class specifies > >> one > >> or more extension points that are implemented by its subcasses ... > >> abstract > >> methods. There isn't a restriction, that there is only one abstract > >> method > >> per class! > >> > >> My proof of concept would go the probably easiest way and just link the > >> first extend with the first child, the second extend with the second > >> child, > >> the third ... you got the idea ;) At a later point it might be useful > to > >> link them using ids (like the names of abstract methods). > >> > >> You could than for instance do some hierarchies like this: > >> > >> BaseClass - Application base class. Navigation on top, two columns with > >> wicket:extend > >> SectionOneBaseClass extends BaseClass - Sub-navigation in left column > >> SectionOneIndex extends SectionOneBaseClass - Navigation on top, > >> sub-navigation in left column and some fancy content in right column > >> > >> I totally agree to anybody who argues that this is already possible by > >> other > >> means. However, to me it seems to be the most natural and elegant way > to > >> do > >> this. > >> > >> As I mentioned before, I don't know Wicket's inner workings too much, > so > >> I > >> will definitely need some pointers to the right directions. > >> > >> My naive guess is that Wicket parses BasePage.html and looks for > >> SecionOneBaseClass.html and the first as soon as it > >> finds a > >> . The idea would know be to just add a counter to this > >> call, asking for the second , rather than the first (I > >> doubt > >> that it's really going to be that easy though). > >> > >> > >> > >> > >> Bruno Borges wrote: > >> > > >> > Stefan, try first giving us an example of what would you like to do. > >> What > >> > I > >> > can see is that you want this: > >> > > >> > BasePage.html > >> > > >> > > >> > BasePage > >> > > >> > This is my child: > >> > > >> > > >> > This is my OTHER child: > >> > > >> > > >> > > >> > > >> > ** Example of a child page:* > >> > ChildPage.html > >> > > >> > > >> > > >> > ChildPage > >> > I'm your child > >> > > >> > > >> > > >> > > >> > Now, given this html, how do you see the Java code structured? What's > >> your > >> > vision? > >> > > >> > On Nov 5, 2007 11:28 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> > >> > wrote: > >> > > >> >> > >> >> > >> >> Eelco Hillenius wrote: > >> >> > > >> >> >> It would be quite feasible to add support for multiple overridden > >> >> >> sections using the above tag names while remaining backwards > >> >> compatible > >> >> >> with existing markup by continuing to support the old > >> > >> >> >> tags working the way they always have. > >> >> > > >> >> > It's kind of a predictable answer, but the best way to push new > >> ideas > >> >> > forward is to supply us with a patch, so that we can discuss some > >> >> > working code. The current committers don't see much in the idea, > but > >> >> > that doesn't mean they wouldn't want to support at least the > option > >> of > >> >> > plugging this in. And hey, maybe some working code convinces us :- > ) > >> >> > > >> >> > Eelco > >> >> > > >> >> > > >> - > >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > > >> >> > > >> >> > > >> >> > >> >> Hi eelco, > >> >> > >> >> I'd love to do a proof of concept here. Admittedly, I don't know > >> wicket's > >> >> inner workings very well. But if I get some support, I'd try > >> implementing > >> >> this. I am currently looking through the code, but can't find where > >> the > >> >> transition between parent and child takes place (in other words: the > >> line > >> >> of > >> >> code that recognizes the wicket:extend tag and takes the appropriate > >> >> action). If somebody could point me to that line I would try to > >> implement > >
RE: Multiple tags on a single base page?
> the complement to abstract is implement not override... names are > important. Arh, sorry, I made my last post before reading yours Igor. Yes, I agree abstract/implement make a great complimentary pair. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> Wouldn't this essentially be the same as using id="header"/> and using WebMarkupContainers on the java side?
> I.e.:
>
> Base
>
Structural markup goes here (see below for explanation of this)
>
More structural markup goes here
>
And again more structural markup goes here too
>
> PumpsBase
> -
>
> A header for all pages to do with pumps
>
>
> Note: no body implemented here - deferred until a more specialized
> class/markups: WaterPumpsBase and OilPumpsBase
>
> WaterPumpBase
> -
> Note: no header implemented here - the general PumpsBase one suffices
> for all pumps pages
>
>
> A body discussing water pumps
>
>
...
>
> On the java side you'd have to addOrReplace(new
> WebMarkupContainer("header")) but it's essentially the same. Or am I
> missing some point?
This is indeed very different. If it were not so then the wicket
developers would never have conceived the need for the current
child/extend tag pair.
The power of inheritance at the markup level is that you can define
markup once in a base markup file that is inherited by all derived
markup files. The derived markup files only supply sections that provide
"specialized sections of markup - the rest, at render time, comes from
the base class.
You would typically use components (panels) within these specialized
sections but using the panel mechanism as you describe above as a
replacement for the powerful markup inheritance feature of wicket is not
possible.
In the panel example you give you must still provide all of the
structural markup surrounding your panel tags in EVERY page's markup in
your system and if you decide to make a system wide change of this
structural markup you must edit every page's markup to reflect that
change. In an OO markup world you provide the structural markup in as
many pages as you want but at render time the only structural markup
used is that provided in the base base - which is very powerful because
you can make system wide changes by modifying only that single base
page's markup. Wicket is the first framework I've seen that allows
proper OO reuse concepts at the markup level.
This is what many people wicket developers with an OO wiring in their
brain are doing right now with the existing child/extend feature - and
to great benefit.
This new feature, or extension of the exiting feature, allows more than
one section of markup to be "specialized" by derived (extended) markups
whereas currently wicket only supports the deferred
definition/implementation of a single markup section in any page. In
other words we want to make a powerful feature even more powerful.
It must be stated again (for the benefit of those who have just recently
joined this thread) that supporting multiple sections whose
implementation can be deferred to extended markups does not equate to
multiple inheritance (a big "no no" in the OO world). Multiple
overridden sections is analogous to the support of multiple abstract
methods whose implementations are provided in classes that extend the
base class - which is supported in all good OO languages, including
Java.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> I totally agree with you, having named extension points would be perfect. > However, I am trying to do a quick proof of concept that can be discussed > before I implement all those nice and shiny features. Hopefully this > prototype convinces some of those sceptics out there ;) I think the anyone who understands how Java supports multiple abstract methods without supporting multiple inheritance should be convinced. If it makes sense for OO languages to support multiple overriddable abstract methods why should wicket be limited to only a single overridable markup section? > I already figured out how to implement this change. Basically, it's only a > single method (MergedMarkup.merge(...)) to change ... but this method has > 275 lines and needs *major* refactoring ... damn. Doh! I reckon you'll have more success adding a completely new tag set because touching the old one get people worried that it might break. If you have a new tag set you are free to define the syntax and behaviour - and you have no chance of breaking how the old tag set works. There's nothing wrong with two tag sets - especially as the new one can be named correctly and will have to support named extension points, eventually. > > However, changing the name of the tag (while it would make perfect sense) > seems to be more complicated. You would have to make sure, that tags are > not > mixed up and decide between two different markup-merging-implementations, > although one implementation is capable of doing the same as the other one > - > and more. Maybe make 'child' an alias for 'abstract' and 'extends' an alias for 'implements' and then use your funky new markup-merging-implementation to handle both multiple (if names are provided) and fallback to single (if no names are provided) - single is then just an ordinary case of multiple where n=1. > > However, I'll consider using a different name and separate implementation > for the prototype. > > -- Stefan > > > > Chris Colman wrote: > > > >> if i were you i would use tags other then extend and child just so you > >> dont conflict. > > > > Yes Stefan, I would think that would be a better approach to use a new > set > > of tags. It also allows you to choose more correct naming (because > > inheritance isn't actually a parent/child relationship so the word child > > just confuses the issue). > > > > Maybe wicket:abstract in the base and wicket:implements (nice - thanks > to > > whoever suggested that) or wicket:override in the derived (extended) > > markup. > > > > I think using IDs up front would also be great, if not necessary, > because > > in Java as would probably occur in wicket mark up, you can have > > intermediate classes that don't implement all abstract methods in a base > > class. Without IDs you won't know exactly which abstract method an > > intermediate class is implementing. > > > > This example hopefully demonstrates what I mean: > > > > Base > > > > > > > > > > PumpsBase > > - > > > > A header for all pages to do with pumps > > > > > > Note: no body implemented here - deferred until a more specialized > > class/markups: WaterPumpsBase and OilPumpsBase > > > > WaterPumpBase > > - > > Note: no header implemented here - the general PumpsBase one suffices > for > > all pumps pages > > > > > > A body discussing water pumps > > > > > > > > OilPumpBase > > --- > > Note: no header implemented here - the general PumpsBase one suffices > for > > all pumps pages > > > > > > A body discussing oil pumps > > > > > > > > I think the tag pairs abstract/implements flow much better from an OO > > perspective than child/extends. It hurts my brain way to much to think > of > > a base class as a child. > > > >> > >> -igor > >> > >> > >> On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > >> > > >> > Well, what I'd like to do is what I explained in my first post. One > >> would > >> > still have a one-one-relationship if it comes to files (Base.html, > >> Base.java > >> > - Sub.html, Sub.java). However, a Base.html might contain more than > one > >> > . So this no longer an exact duplicate of the > parent- > >> child > >> > relationship that is already specified by the java class hierarchy. > It > >> now > >> > wo
RE: Multiple tags on a single base page?
> > Wouldn't this essentially be the same as using > id="header"/> and using WebMarkupContainers on the java side? > > > yes it would be exactly the same thing. If you think that these are the same then you've missed some vital plot points of the movie that it child/extend. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> Hmmm... more tags? I thought you guys liked Wicket because it's plain html > support. Now looks like there's a big interest in having more tags. If > this is true, why don't we go back a few years, or move to JSF? Let's give > Wicket support to Tag Libraries too :) > These aren't just like other tags - not having these is like removing the abstract keyword from the Java language. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> Hey Chris, I would need some lobbying here! ;)
>
> -- stefan
You're doing a great job Stefan - especially now I see that you've implemented
it - excellent job!
Are we both seeing something here that other people can't see? It wouldn't be
the first time in my life I was in that position - only years later do people
go "oh yeah" what a great idea...
I can only guess that most people haven't actually discovered the power and
reuse facilitated by the child/extend tag because if they had then it's not
such a great stretch to see the power of supporting more than one extendible
section - we're just arguing over multiplicity, not the extendible section
concept itself.
Most of the "panels can do that" arguments, in my mind, disparage the existing
child/extend concept as much as they do the proposed support for multiple
single extendible sections.
The, "I can do that with panels" argument sounds like C programmers back in the
early 90s saying, "I don't need C++ I can do everything in C with function
pointers". Well you probably could but by embarking on a short learning curve
you could be 1000x times more productive.
Someone asked for another explanation of the difference so I'll do that again
in a following post.
>
>
>
> Chris Colman wrote:
> >
> >> Wouldn't this essentially be the same as using >> id="header"/> and using WebMarkupContainers on the java side?
> >> I.e.:
> >>
> >> Base
> >>
> >
> > Structural markup goes here (see below for explanation of this)
> >
> >>
> >
> > More structural markup goes here
> >
> >>
> >
> > And again more structural markup goes here too
> >
> >>
> >> PumpsBase
> >> -
> >>
> >> A header for all pages to do with pumps
> >>
> >>
> >> Note: no body implemented here - deferred until a more specialized
> >> class/markups: WaterPumpsBase and OilPumpsBase
> >>
> >> WaterPumpBase
> >> -
> >> Note: no header implemented here - the general PumpsBase one suffices
> >> for all pumps pages
> >>
> >>
> >> A body discussing water pumps
> >>
> >>
> > ...
> >
> >>
> >> On the java side you'd have to addOrReplace(new
> >> WebMarkupContainer("header")) but it's essentially the same. Or am I
> >> missing some point?
> >
> > This is indeed very different. If it were not so then the wicket
> > developers would never have conceived the need for the current
> > child/extend tag pair.
> >
> > The power of inheritance at the markup level is that you can define
> > markup once in a base markup file that is inherited by all derived
> > markup files. The derived markup files only supply sections that provide
> > "specialized sections of markup - the rest, at render time, comes from
> > the base class.
> >
> > You would typically use components (panels) within these specialized
> > sections but using the panel mechanism as you describe above as a
> > replacement for the powerful markup inheritance feature of wicket is not
> > possible.
> >
> > In the panel example you give you must still provide all of the
> > structural markup surrounding your panel tags in EVERY page's markup in
> > your system and if you decide to make a system wide change of this
> > structural markup you must edit every page's markup to reflect that
> > change. In an OO markup world you provide the structural markup in as
> > many pages as you want but at render time the only structural markup
> > used is that provided in the base base - which is very powerful because
> > you can make system wide changes by modifying only that single base
> > page's markup. Wicket is the first framework I've seen that allows
> > proper OO reuse concepts at the markup level.
> >
> > This is what many people wicket developers with an OO wiring in their
> > brain are doing right now with the existing child/extend feature - and
> > to great benefit.
> >
> > This new feature, or extension of the exiting feature, allows more than
> > one section of markup to be "specialized" by derived (extended) markups
> > whereas currently wicket only supports the deferred
> > definition/implementation of a single markup section in any page. In
> > other words we want to make a powerful feature even more powerful.
> >
> > It must be stated again (for the benefit of
RE: Multiple tags on a single base page?
> > Given these subtle problems with this approach, I admit I'm warming to > > the multiple extend/child idea. > > im oposite - if i have X extends in a page, whose extend should be > preferred (e.g: manipulating the head or a part outside of itself) ? I'm not sure I understand the issue you raise but so please forgive me if I've misunderstood: Presumably you don't have an issue with multiple abstract methods in Java classes? As Java and Wicket only support single inheritance there is no issue as to which base class/page child section is being extended in a derived class/page (that only ever happens in a multiple inheritance paradigm and no one is proposing we go down that path!) - the identifier of an implements in a derived page will only ever resolve to a single abstract tag in a base page. There's no confusion here I don't believe. In Java you name methods carefully and appropriately and the compiler warns you if you have duplicated a function signature. Same would happen in wicket. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> > And if somebody really needs 5 child areas, something else might be even > > messier than the page's constructor. I rather think that 2, 3 or in rare > > cases even 4 ids could make sense. > > i must disagree - i have a basepage which defines the default layout on a > project, i.e. header, top-nav-container (imprint etc), navigation, > content-left/-right/main, footer - this makes 7 panels which are added on > the > way down to the resulting page... > > but i don't use abstract methods for this, for it can get messy (as stated > in other comments). How can it get messy when it's not yet possible to do in wicket? You mention 7 different panels which is > 1 and so not currently supported by wicket's current child/extends feature. Unless you mean that trying to override 7 different sections with only one child/extends feature - but now my brain hurts - the anticipated messiness my be a result of trying to implement multiple specialized sections without support for it being in wicket yet ;) (but given that many people are starting to warm to the idea you might be able to do this sooner rather than later!) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> Chris Colman schrieb: > > The beauty of the multiple extend/child idea is that it's not a > > completely new concept we're talking about here - it's merely an issue > > of supporting n>1 instead of arbitrarily fixing n=1 like it is now. > > 1 Question: Who dominates Who and Why? > > If you extend 1 class by class you create specialisations that dominate > each other, but here you just mess together some classes - so why should > which class dominate? If we manipulate a headertag? If we have same > namespace? If we have different securitylevels? Wich class is > responsible for all this? Why? Dunno what you mean by "dominate" or "mess together some classes". No one is talking about mess - the whole point of this feature is avoidance of mess - in the same way OO brings about reduced complexity in code the same thing can happen with markup. We're not proposing multiple inheritance - which indeed causes mess. We're talking single inheritance which means single lineage. Each page only has a single base page. It's easy for Wicket to perform the resolutions and merge markup from base and derived pages. I know this because it already does it and it works fine. We're just proposing to remove the restriction that it can only do it for just one section of your base page - that's all, nothing revolutionary - just evolutionary. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> > How can it get messy when it's not yet possible to do in wicket? > > i believe it has been shown multiple times already that it CAN be done > with vanilla wicket... I didn't like the look of any of those 'coded' solutions. They were not from the coding elegance book I've read. They also mean I'm starting to arrange, layout and compose my pages in Java instead of markup (meaning my graphic designers lose control). The abilty to control layout completely at the markup level instead of the Java level is why I moved to Wicket from another framework in the first place and I guess a lot of others have too. The division of responsibility in Wicket is something not achieved by any other framework I have used which is great because I don't think I'm going to be able to teach my graphic designers Java any time soon. I also wouldn't classify as "vanilla" that alternative, workaround using low level plumbing code that hooks into the lifecycle methods. It's more like a honeycomb chocolate fudge, banana sundae, with 1" thick caramel sauce sprinkled with 100s and 1000s ;) - it sounds great on the menu but after you've finished it you're left wondering if you made the right decision. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> a lot of people are saying that this can be implemented with panels, > and that is true. but actually implementing this with fragments will > make it look very similar to this new strategy and does not have the > id collission problem, because components ARE nested in two different > containers: I've never used fragments but I just read up on them... I may be wrong but it looks as if you have to define all possible fragments that might appear in a page to that page. It doesn't seem to follow the natural, organic flow of markup inheritance where a base page can be enhanced by substituting base a page section with markup defined in derived/extended pages - that only happens with the child/extends feature from my understanding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
Presumably the coded work arounds that don't rely on child/extends mean that the structural markup of each page is used instead of just that of the base page - and that would spell maintenance issues. Without using child/extend then ALL the structural markup in each page is used for each render - NOTHING is pulled from the base page markup (kind of makes me wonder why we need base page markup if not using child/extend - but that's another topic!). A change of layout structure would mean changing all page markups - yuck - or do you guys not care about your graphics designers - "arh, that's their problem if they want to do a site wide change!" I think the fundamental thing that most people are missing is that each component must be well formed XHTML, complete and self contained. If it starts a (or ) then it must also end it. Divs (and tables) are the basic structural elements of markup. One component can't be the start of a structural span of markup, the next few components content sections for that span and then the last component ends the structural span - that is not possible because each component must be well formed and complete. So this infers that structural markup typically is stored in page markup and "wraps" markup that inserts various self contained components. Now here's the thing: without using child/extends then that structural markup must be carefully defined in EVERY page markup because wicket does not do the funky inheritance merging when you don't use the child/extends tag. So if you want to change a border in between two components you must change it in EVERY page markup. That would suck. Alternatively, if you do use the current child/extend you end up having to bang multiple components into the overridden section which means that you also bang in the border that exists between them - so now the border markup is duplicated many times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> Korbinian Bachl wrote: > > you missed solution3: > > the real-wicket-way(tm) for multiple content-places in a tied page-area: > > Whaaa, I seriously hope this is not the real-wicket-way! My brain hurts! > > A framework is supposed to make things easy and readable! The code below > is just way too complicated to achieve something that should be easy... > > Preferably when doing simple stuff like this, I don't want to be > confronted with things like rendering (and adding render hooks), or with > keeping extra state about components being or not being initalized. Also > I don't want to have to copy this boiler plate for every time I want to > place some kind of component "hole" in a base page! > Well said! I agree wholeheartedly. I suppose the reason I'm so passionate about this new multiple child/extends support is that it helps preserve simplicity for the wicket developer instead of making our more complex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> and in extending classes you can easily do this:
>
> protected void initialize() {
>
> addToAnything(new AnyPanel("id"));
> addToAnything(new AnyPanel2("id2"));
> }
So now you're proposing the Java code is defining the layout of
components? That's what the markup's job is I thought.
What I, and probably many others, like about wicket is that the Java
code is just a "slave" to the markup - not the other way around. The
graphic designers are free to control where everything goes in markup
and so long as I have implemented a Java class for each panel that they
want to use then everything just works. They can rearrange the whole
look and layout of the side without me touching my Java code.
Your solution is starting to look very much like the Echo2 solution -
where layout is controlled entirely in Java.
Also: Does your addToAnything method assume a regular, repeating pattern
- like panels in a column or row? What if the panels I want to
specialize in derived pages are not laid out in a grid or array
structure: eg., a sub header that spans the entire page width plus a
side menu on the left plus a body section in the middle - all separately
implemented at various levels in the page hierarchy but with the
structural HTML that lays them out specified in one place in the base
page?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> ok tell me with 2 examples what is soo different about having 2 panels (or > fragments) > in a page and implement that in a sub page or having 2 wicket childs in a > page and implement those in a sub page. Ok, here we go... (well one example at least - it's getting late here ;) ) I'm not sure what angle you're coming from: there seems to be two things to argue about here: 1) the value of markup inheritance as facilitated by the ability to "override" or "defer implementation" of a single section of a base page, via the existing child/extends tags, to a sub page's markup. 2) the multiplicity of overridden sections (ie., allowing more than one) The first point is easy to argue for - if you don't have an tag in a page then that page, when rendered, uses ALL of the markup of that page - it does not merge any markup with a base page. In other words, you need to set up the structural markup around your panels etc., identically in every page if you want to have the same look and feel across your whole site. If you change the structure of your page you need to edit EVERY page... nasty! If you do have a tag in your base page and in sub pages then wicket works in a much more clever and powerful way: the whole of the base page markup, except for the section is "merged in" when rendering the sub page. In other words - all subpages share the same structural markup surrounding the section. This is very powerful and it's exactly the same concept that's been used in OO languages for the last 20 years. The sub pages have a chance to "specialize" the appearance of the page, albeit (currently) in only one section. No OO language limits the number of methods that can be "specialized" in a sub class to just one method - it would be very restrictive, would make no sense and there would be no logic in such a limitation. In the same way there is no logical reason why the number of "specialized" sections in sub pages in wicket should be limited to just one. What Stefan has brilliantly done is created a wicket patch that does away with this unnecessary limitation of only one specialized section per page. So if you already use and see the value in the child/extend take then support for Multiple "specialized" sections per page is just a simple multiplicity argument. Do you ever find yourself creating more than one overridden method in a Java class? Well then you'll probably feel the urge to do the same in markup now once you grasp the power of markup inheritance. For those wanting an example I'm not a graphic artist, but a developer, so naturally I used a software modeling/coding tool to illustrate an example of how such multiplicity is useful: The picture is a .vcm model (3kb zipped) and is downloaded from: http://www.stepaheadsoftware.com/products/javelin/examples/multipleSpeci alizedSections.zip You can use freeware version (1.3MB) of the Javelin modeling tool to view it, which can be downloaded from: http://www.stepaheadsoftware.com/products/javelin/javelind.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> public DerivedPage extends BasePage {
>
> private String name;
>
> public DerivedPage(String name) {
> super();
> this.name = name;
> }
>
> public abstract addAbstract1(String abstractId1) {
> add(new NamePanel(abstractId1, name));
> }
> }
>
> This code is broken, since you're constructing NamePanel before name
has
> been initialized. Someone later in this thread shows a better way to
do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times
you
> must maintain a flag to ensure you only add your panels once.
>
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.
Good to hear!! Multiple abstract/implements (child/extends) lets us
avoid the ugly plumbing code suggested in previous posts as an
alternative. I'd rather extend an elegant existing feature with
multiplicity than have to add low level plumbing code to my apps that
assumes a knowledge of the lifecycle methods (eg., onBeforeRender -
never needed to override that method for anything else before now) and
requires me to hook in to the lifecycle at various obscure places like
suggested. I think this goes against the wicket's simplicity motto way
more than supporting multiple child/extends sections does.
The beauty of the multiple extend/child idea is that it's not a
completely new concept we're talking about here - it's merely an issue
of supporting n>1 instead of arbitrarily fixing n=1 like it is now.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple thread
> ... > > 5) Conclusion > > In conclusion, the proposed change: > - is useful > - does not have to be used if you don't like it > - is 100% backwards compatible > - it introduces no new tags (if using child/extends) > > I also do not see any real issues. This is purely about merging markup > when rendering, I think the analogies between this and OO concepts in > Java are clouding the issue! > > Regards, > Sebastiaan Great summary Sebastiaan! I just thought of a possible, even more powerful, improvement (whoops!) What if the base page sections (child or abstract tag) were "optionally" overridden in a derived page. Ie., the section in the derived page markup is used if supplied otherwise Wicket defaults to using that provided in the base page. That's immensely powerful because you could provide some default markup in the base page and that will be used if the derived page does not provide an implementation of that section. A derived page now only needs to provide override sections for sections that it actually needs to override. It makes 'abstract' not a good choice for a tag name because abstract implies there is no implementation in the base page. In this case we could drop the OO language terms and use easy to understand terms for the tags like " in a base page section and in a derived page section. Even my graphic designers could understand a tag pair called default/override! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple thread
> > The advantage of having this separate project > > is that such inheritance would be available for people who like it, > > and hey, maybe in the longer term you have something that works so > > good that you can convince people based on something that works. > > Executable code works much better than simply words when it comes to > > that ;-) Having it as a separate project is better than no project at all. I'd be glad to use that if a separate project is the only option on offer. As it's a separate project we'll need different tag names. I'm not sure if you caught my 11th hour submission on your "final summary" post: Suggested minor modification to the design: Call tags "default" and "override" instead of "abstract" and "implements" - it's less *techie* plus it allows us to define a default markup section in a base page that can be "optionally" overridden in any derived pages. That's even more OO and allows even greater simplicity through reusability. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> heh, wellyou can be against this, but i think if we take a vote > right now most core-devs with binding votes will vote this down I still can't see the reason for the negativity of some of the core-devs: this is an existing feature. If the feature sucks so bad why did people have the inspiration to add it in the first place in the beginning of wicket's life? We're just proposing to enhance an existing feature - evolution not revolution. > > so we can make this pluggable and someone can put it on wicket-stuff > or there is a chance it wont make it in at all... It seems strange to want to make a more powerful version of an already existing feature accessible only via a plug in. Maybe some of the core-devs are starting to lose a bit of their zing or their desire for a challenge - a zing that comes so naturally in a project's infancy. > > -igor > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple thread
> That is what I'd suggest as well, since it involves the least amount of > change. As an added bonus, if no id's are added and 2 > sections are used, it could throw an exception (which it currently does > not do, it just silently ignores the second ). That would be magic! While we're at this epic moment after spending days thrashing this out could we spend just 3 extra minutes to investigate implementing standard Java method like behavior for this feature? Ie., In the case that no override is provided in a derived page, simply use the markup in the tag in the base page. Then it would work like methods work in Java - and it's probably how most Java developers would naturally expect an OO framework like wicket to work anyway. Intuitively it seems like an easy to implement option in the framework: the / feature is already merging code from the base page anyway - if there is no override tag in a derived page then it simply pulls the markup from the base page's tag. > > Regards, > Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple thread
> Hi, > > Actually, Wicket already works like this. It does *NOT* require the > , and if it's not present it just renders the contents of > the . (Just tested this with beta4). Awesome! [This behaviour must have changed since 1.2.6 because I tried removing the tag in a derived page using this version and the whole of the derived page got rendered - ie., it did not merge in any markup from the base page. If later versions have fixed this already then that's massively awesome indeed] > > Furthermore, your patch works exactly the same as far for multilple > child sections (as far as I can tell, or otherwise it should for > backwards compatibility), and does precisely what both you and Chris want. Awesome! So it all sounds like a very low risk improvement of the existing functionality - cool! Sorry to all of those who've put up with such a long, sometimes noisy thread but I think that's just part of the enthusiastic, collaborative process that popular open source projects such as Wicket have become and it's what continues to make them great and evolve to become even greater. I present to you just one final tweak at the edges for your comment: The OO puritan in me would love to see aliased to so that developers could use either (deprecated but still available for backwards compatibility) or - it won't break existing pages and lets new people use a more naturally fitting and more accurate tag: Which would flow more naturally and be more easily understood by new users reading the documentation? A) If you don't 'extend' a 'child' section in a derived page wicket uses the child section provided in the base page. (Comment: Extend a child? We're not extending the child section - we're replacing it!) B) If you don't 'extend' a 'default' section in a derived page wicket uses the default section provided in the base page. (Comment: Extend? It is the page you are extended by overriding one or more of its default sections. Again you aren't extending a default section you are replacing it!) Or even - now I'm really pushing my luck asking to provide two aliases ;) C) If you don't 'override' a 'default' section in a derived page wicket uses the 'default' section provided in the base page. (Comment - arrhh beautiful - 100% accurate and natural) At university I remember a lecturer telling a story of an interview with one of the creators of Unix. He was asked if he had any regrets over his illustrious career and he said "Yes I do, I regret naming the 'create' function 'creat' instead of 'create' just to save one byte!". How much frustration does a bad name cause? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JPA best-practices?
> > > i plan to use JPA together with Wicket. Are there any battle-proven > > > best-practices out there of how to handle EnityManagers and > Transactions? > > > > > > What do other people use (no, not the spring crowd ;) ? > > > > > > One EntityManager per Request seems to be the obvious idea and a guice > > > Provider may help with that. Does anyone have serious experiences with > > > that or other suggestions? > > > Have you seen exPOJO (http://expojo.com) yet? It an open source, very lightweight framework, free for use in commercial and open source apps, which sounds like what you're looking for. It allows you to build a completely POJO object model and persist it via a generic transparent persistence interface that has plugins for the various popular transparent persistence engines: Hibernate (implemented), JDO/JPOX (implemented) and JPA (will be implemented if sufficient demand) The obvious benefit in such an approach is that your POJO model and the services that you provide to implement business rules etc., remain completely portable to different persistence engines - ie., no vendor lock in. As well as "wrapping" the various persistence engines it also provides dependency injection without resorting to separate XML/bean mania - it's all done very quickly and concisely and automatically in Java - which means you have the benefit of compile time error checking instead of finding out about configuration errors at run time as you do in Spring. The only XML config is the usual configuration of an exPOJO filter and start up/shut down (ServletContextListener) listener in your web.xml. These are just a few lines that only need to be set up once and never need adjusting no matter how big your project grows. You can read more about it and download (~200kb!) from: http://expojo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple thread
> I give up. Looks like this enhancement is really receiving positive votes. > :) :) :) :) :) :) :) :) :) Just some of the many happy faces! > In my second reason, I point to something that is... the _core_ of wicket: > binding Java objects (Components) to HTML tags. So, not having this > binding, we could lose great features. Seeing from this point of view, my > suggestion is to allow these new > call-whatever-you-want-here-from-abstract-to-implement-to-default-to-etc > tags only when they have been declared in Java: It's great that you're now at the level of suggesting improvements! And I'm already hating myself for my following comments but in the interest of keeping this enhancement simple: My first thoughts about your suggestion are: I wonder if components associated with default/overridden markup should be treated any differently. I have always found Wicket's error detection on missing tags or unbound components to be excellent. It would still continue to work in the exact same way without needing to define, as you suggest, at the Java level, special components that will bind to abstract (default/override) markup sections. I think the elegance of the new feature is that is purely an enablement (I think I just invented a new word!) of multiplicity on an existing feature and some new tags to more accurately define the feature (previous tags are aliased to the new ones for backwards compatibility). If we start having to define "overridden" or abstract components at the Java level then it turns into a whole 'nuther beast and I worry that we lose some of the genericity of component definition that we have now in wicket. On first glance I believe that your suggestion may create problems for backwards compatibility with existing pages using the current feature. It would mean people would have to add addAbstractMarkup to their existing pages to allow them to work in the new system which would be a bad thing I think. Ok, I can stop hating myself now ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CAPTCHA clarity in post 1.2.6 releaes
I'm using the wicket extensions CAPTCHA feature which works perfectly except: I know the purpose of CAPTCHA is to make the text unreadable to a certain extent but it's *TOO* good at making the text unreadable - such that humans often get it wrong too. I have a client who has complained that while's it's good that a computer can't decipher the letters it's bad that he has trouble doing it. Dang those customers! Just think how much more successful we could all be if it wasn't for those pesky customers... ;) I am currently using wicket 1.2.6. I was wondering if any post 1.2.6 releases have "improved" (depending on your perspective) the capture appearance to make it slightly more readable by humans. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CAPTCHA clarity in post 1.2.6 releaes
> It is still pretty nasty in the 1.3 series. I got around the issue > somewhat by throwing out several letters that could be indistinguishable > after deformation. Things like "h" and "n," "I" and "1," and "t" and > "f." Good idea! I tried throwing out all the letters and using only numbers but even then there was a lot of ambiguity between 1 and 7. I might try going back to letters and avoiding the letters that you mention. > But yeah, about 10% of the time, they get pretty bad. Yeah it gets so hard to read that you almost need software to do the recognition for you =] > > Chris Colman wrote: > > I'm using the wicket extensions CAPTCHA feature which works perfectly > > except: > > > > I know the purpose of CAPTCHA is to make the text unreadable to a > > certain extent but it's *TOO* good at making the text unreadable - such > > that humans often get it wrong too. > > > > I have a client who has complained that while's it's good that a > > computer can't decipher the letters it's bad that he has trouble doing > > it. Dang those customers! Just think how much more successful we could > > all be if it wasn't for those pesky customers... ;) > > > > I am currently using wicket 1.2.6. I was wondering if any post 1.2.6 > > releases have "improved" (depending on your perspective) the capture > > appearance to make it slightly more readable by humans. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CAPTCHA clarity in post 1.2.6 releaes
> i hope you guys realize that this isnt a wicket issue, its an issue > with the captcha lib that wicket uses - thats what is generating the > image. I realized that it was a third party thing. If it was written by the wicket devs it would rock like everything else they write! > so why not simply integrate a different lib into your own > component? possibly submit that as a proposal to replace the current > one... Sounds like a good idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CAPTCHA clarity in post 1.2.6 releaes
The trouble is that the answers to the kitten questions usually have a small number of possible combinations: 1 - 5 roughly so on average a robot may be successful 20% of the time. > thoof.com has a better captcha: select the kittens. I'd love to know > if it works for them or not. > > Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JPA best-practices?
> Chris Colman schrieb: > > > The obvious benefit in such an approach is that your POJO model and the > > services that you provide to implement business rules etc., remain > > completely portable to different persistence engines - ie., no vendor > > lock in. > > well, i thought that was JPA was all about !? No, definitely not! JPA was all about creating a standard that Hibernate could conform to. Remember there *already* was a standard for Java persistence: JDO. JDO implementations such as JPOX and others implement both JDO (obviously) and JPA but it is not possible for Hibernate to provide all the features of JDO and so it could never implement the JDO standard - hence a less powerful standard had to be created so that Hibernate could play the "standards" game. Enough of the history lesson already ;) > > As well as "wrapping" the various persistence engines it also provides > > dependency injection without resorting to separate XML/bean mania - it's > > all done very quickly and concisely and automatically in Java - > > Thanks, that´s what guice is great for, and it is really neatly > integrated with wicket. Yes, exPOJO and guice are great alternatives to a heavyweight and XML based approach like Spring. exPOJO, being a lightweight implementation of the "exposed POJO domain model pattern" has the benefit of making it easy to port apps between Hibernate, JDO and JPA without changing any of your model code or 'Service' classes. You only need to implement an engine specific Repository class as repositories are the only classes that contain engine specific API calls - ie., mainly the queries. If the slow performance of Hibernate's "reflection based" dirty state checking on large object graphs has you worried then you can quickly change your underlying persistence engine over to a "byte code enhanced" solution, like for example JPOX, with the lightning fast dirty state checking and other performance gains that brings. > > > http://expojo.com > > I´ll take a look anyway, thanks. > > cu uwe > > -- > > THOMAS DAILY GmbH > Adlerstraße 19 > 79098 Freiburg > Deutschland > T + 49 761 3 85 59 0 > F + 49 761 3 85 59 550 > E [EMAIL PROTECTED] > www.thomas-daily.de > > Geschäftsführer/Managing Directors: > Wendy Thomas, Susanne Larbig > Handelsregister Freiburg i.Br., HRB 3947 > > > - > 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: JPA best-practices?
> Evan Chooly wrote: > > > >> Do you know if theres any plans on making a maven2 archetype for > qwicket? > > > > That's a definite feature i plan on adding as soon as I can. As a > > noted maven hater, though, it'll take some time and libations to help > > me swallow my pride. :) > > > > Good luck! Archetypes are really a pain, because of the template text > strings in the source that keep them from compiling in place, so they're > hard to code, test, and maintain. I just abandoned mine. > People can almost as easily rename classes and packages after the fact, I've rationalized. > Alleluia brother - I hear what you're saying! Whoever decided declaring stuff in type safe, compile time checked Java was hard? I've certainly never found writing or updating Java classes hard - probably because that's what I do every day! Give me Java config over XML config any day. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JPA best-practices?
> Chris Colman wrote: > > It seems it's also possible for a few other ORM tools to conform to that > standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne and > others. That's my point. > > Which would you rather depend on; exPOJO or JPA? Two different things: exPOJO is a lightweight, dependency injection framework with support for the "exposed POJO domain model pattern" for highly productive app development. It provides a very concise and simple interface declaring the essential generic services of a transparent persistence engine. 'Transparent' is the key word here so the interface needs only be extremely minimal but this generic interface is massively powerful. Out of the box it has JDO and Hibernate implementations of this interface and others (including JPA) can be supported in under 60 minutes if required. JPA is a different thing altogether - it's an ORM standard. The trouble is that it had to make compromises to allow certain popular ORMs to implement it. exPOJO does not try to be another ORM standard. It just takes the best the exposed domain model pattern has to offer and uses that such that the only components with engine specific references are the repository components that you build that have engine specific queries in them. All the rest can be handled generically. > > /Anders > > - > 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: JPA best-practices?
> And you need a framework for this? Come on! > An extremely lightweight framework that gives me dependency injection and helps manage the myriad of repository and service classes I end up with in large enterprise systems? All without the need for heavyweight Swing and the XML hell and runtime error opportunities that delivers... Need a lightweight framework that gives me all that and lets me port my apps between JDO <-> Hibernate with miniscule effort? Hell yeah! We're also about to open source some key infrastructure libraries that are deployed to exPOJO which means that JDO (JPOX, Kodo etc.,) users can use them as well as Hibernate users. A big issue with the adoption of many Java libraries is that they hard code dependence on a particular persistence solution: JDBC, EJBs, Hibernate, JDO etc., which limits their appeal if you happen to have a "favorite" that isn't their favorite ;) Deploying to exPOJO means a library developer can expose their wares to the maximum audience possible by providing repository components for the major transparent persistence engines (Hibernate, JDO etc.,). It's also useful if you want to go with an ORM but your company or client hasn't decided on one yet - just pick your favorite ORM and then start development while you're waiting on their decision. When they finally make up their mind you'll have an easy time porting your app. > > Chris Colman wrote: > > > > exPOJO is a lightweight, dependency injection framework with support for > > the "exposed POJO domain model pattern" for highly productive app > > development. It provides a very concise and simple interface declaring > > the essential generic services of a transparent persistence engine. > > 'Transparent' is the key word here so the interface needs only be > > extremely minimal but this generic interface is massively powerful. Out > > of the box it has JDO and Hibernate implementations of this interface > > and others (including JPA) can be supported in under 60 minutes if > > required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Questions about wicket features
> Hello > > I've browsed over the wicket documentation and examples. There are a > couple of things I don't seem able to determine. So I would really > appreciate your input on this questions. > > 1. Can I write a web application without coding any HTML whatsoever?... > I mean, is there some kind of "html" or "whole page" component which > renders an entire HTML page? You need to use something like Echo2 or Echo3 to write pure Java web apps with no HTML whatsoever. All the HTML and all the AJAX is completely transparent to the developer - it's more like writing a desktop app than a web app which has benefits if you come from a Java/C++ background and some disadvantages if you like having the power to hack around with HTML and Javascript code. With wicket you're still in control of the markup (HTML) which means you have to write it but it's pretty straightforward. There is support for a single section of markup to be overridden (inheritance) from a base page markup to a derived page markup which means you can perform some level of markup reusability at the page level. On some occasions I've found the need to have multiple sections in a base markup to be 'overridable' in a derived markup pages but this is not yet possible as far as I know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using standard query notation ?productId=3 instead of /productId/3
I have a client who employs a professional SEO guy. He's told the client that my use of /productId/3 (as per the wicket standard) is not kosher with the search engines and that I should be using the traditional ?product=3 query stuff as the search engines produce better rankings for pages with those types of queries. A. Is he right? B. Can I flick a switch in wicket to generate traditional queries? Regards, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Serving wicket JS from CDN?
>-Original Message- >From: Jan Riehn [mailto:jan.ri...@1und1.de] >Sent: Thursday, 4 April 2013 1:31 AM >To: users@wicket.apache.org >Subject: AW: Serving wicket JS from CDN? > >Hello Chris, > >I'm not sure, if i've got the point - you want to extract your own JS/CSS >to a cdn? No, not my own JS/CSS but the 'standard' ones that Wicket uses. I wanted to be able to find a publicly available CDN that served the standard Wicket JS/CSS files and have my wicket apps point to those URLs instead of pulling them from the same server that is serving the wicket pages. >I've already used a similar implementation to this: >http://techblog.molindo.at/2011/03/serving-wicket-resources-from-cdn.ht ml > >Regards, > >Jan > >Von: Chris Colman [chr...@stepaheadsoftware.com] >Gesendet: Dienstag, 2. April 2013 19:27 >An: users@wicket.apache.org >Betreff: Serving wicket JS from CDN? > >Is anyone thinking about serving JS required by wicket (eg., jquery etc) >from a CDN? > >If we started serving commonly used JS used by wicket from a central CDN >then more and more browsers visiting Wicket based sites would be starting >to cache JS used commonly across the 'Wicketsphere' so further visits to >other websites in the wicketsphere would require no download. > >Caching of these common, static resources would reduce the bandwidth >usage/traffic on the webservers hosting wicket sites. > > >Yours sincerely, > > > >Chris Colman > > > >Pagebloom Team Leader, > >Step Ahead Software > >[cid:image001.gif@01CE3023.7F5E5400] > >pagebloom - your business & your website growing together > > > >Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 > >Email: chr...@stepahead.com.au<mailto://chr...@stepahead.com.au> > >Website: > >http://www.pagebloom.comhttp://www.pagebloom.com/> > >http://develop.stepaheadsoftware.comhttp://develop.stepaheads oftw >are.com/> > > >- >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Make wicket fetch js from different server
What is involved in telling wicket to fetch its js (jquery etc) from a different server. It doesn't have to be a true CDN server just a different server to the one the wicket app is running on. Would this require using wicket-cdn or is there an easy way to just tell wicket to fetch its js from a different server?
RE: Make wicket fetch js from different server
As with everything else with wicket - that's just far too easy! :)
Thanks Martin
>-Original Message-
>From: Martin Grigorov [mailto:mgrigo...@apache.org]
>Sent: Saturday, 1 February 2014 7:06 PM
>To: users@wicket.apache.org
>Subject: Re: Make wicket fetch js from different server
>
>Hi,
>
>getJavaScriptLibrarySettings().setJQueryReference(new
>UrlResourceReference("some url"))
>
>Martin Grigorov
>Wicket Training and Consulting
>
>
>On Sat, Feb 1, 2014 at 8:02 AM, Chris Colman
>wrote:
>
>> What is involved in telling wicket to fetch its js (jquery etc) from
a
>> different server. It doesn't have to be a true CDN server just a
>> different server to the one the wicket app is running on.
>>
>> Would this require using wicket-cdn or is there an easy way to just
tell
>> wicket to fetch its js from a different server?
>>
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Modals and Bootstrap Modals - sizing issues
We are using Wicket with Bootstrap which is fine except for modal window. With Wicket it appears as though the modal window provides all the markup for the out modal 'window'. We can provide HTML for the panels within that but the outer modal seems to be Wicket generated. This seems to be causing problems when using responsive Bootstrap because the calculations of the grid sizes are based on the screen and not the width of the modal window and so the form fields end up being wider than the form itself. Has anyone else had this problem? Is there a work around? We're not using the Wicket 'enable bootstrap' flag in the settings as we support bootstrap and non bootstrap markup within the same wicket app. Regards, Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket Modals and Bootstrap Modals - sizing issues
Would the l0rdn1kk0n / wicket-bootstrap community have dealt with this issue already or do they not support Wicket/Bootstrap modal windows in 'responsive' mode? Regards, Chris >-Original Message- >From: Martin Grigorov [mailto:mgrigo...@apache.org] >Sent: Tuesday, 18 February 2014 6:32 PM >To: users@wicket.apache.org >Subject: Re: Wicket Modals and Bootstrap Modals - sizing issues > >Hi, > >I think you will need to tweak some CSS rules. >Wicket's ModalWindow main CSS class is 'wicket-modal'. So you have to >provide CSS rule that sets the width for any .form-control in .wicket- >modal. >You can either use LESS/SASS to generate different rules for the different >screens or with CSS media queries. > >Martin Grigorov >Wicket Training and Consulting > > >On Tue, Feb 18, 2014 at 8:04 AM, Chris Colman >wrote: > >> We are using Wicket with Bootstrap which is fine except for modal >> window. >> >> With Wicket it appears as though the modal window provides all the >> markup for the out modal 'window'. We can provide HTML for the panels >> within that but the outer modal seems to be Wicket generated. >> >> This seems to be causing problems when using responsive Bootstrap >> because the calculations of the grid sizes are based on the screen and >> not the width of the modal window and so the form fields end up being >> wider than the form itself. >> >> Has anyone else had this problem? Is there a work around? >> >> We're not using the Wicket 'enable bootstrap' flag in the settings as we >> support bootstrap and non bootstrap markup within the same wicket app. >> >> Regards, >> Chris >> >> - >> 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
Header contributions from component in modal window
We have a problem where we have a component that pulls in its header contribution JS perfectly fine when the component is added to a page, however, when added to a form in a ModalWindow it doesn't work. I guess this is because we set up the page so that any generic modal can be opened (using ModalX) at page render time - at that time it has no idea what panels (and their components) will exist when the form is actually opened. Anyone else experienced this problem? Obviously the component fails because the header contribution of the component doesn't seem to work in a ModalWindow used in this 'generic' way. Is there any work around for this? Yours sincerely, Chris Colman Pagebloom Team Leader, Step Ahead Software pagebloom - your business & your website growing together Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 Email: chr...@stepahead.com.au <mailto://chr...@stepahead.com.au> Website: http://www.pagebloom.com http://www.pagebloom.com/> http://develop.stepaheadsoftware.com http://develop.stepaheadsoftware.com/>
Wicke website makeover time?
Hi fellow wicketeers! We all know that Wicket has to be the most awesome and productive Java UI framework around but I am worried when I point new clients to the Wicket website because it's look and feel is possibly a little dated or '2007ish style'. I feel like the look and feel of the Wicket website doesn't do justice to the full awesomeness that we all know wicket has. We all know that, using the wicket Java UI framework it's possible to create websites with *any* look and feel but unfortunately many clients don't have this same technical awareness and see the website for Wicket, a framework for building web applications in Java, and assume that the Wicket website itself is an example of the type of webapp/website you'll end up with if you build it with Wicket - which we all know is not the case: we're building awesome AJAX enabled, modern, sexy Bootstrap templated webapps in Wicket. A few years ago someone had produced a prototype of a refurbished Wicket website that looked really quite nice but it never was deployed to the live server for some reason. These days I think most developers know that it's fairly easy to make a great, modern looking website using one of the many Bootstrap customizations (eg., Bootswatch). First question: Does anyone else think a wicket website makeover is overdue (or are most people happy with the current look and feel)? If the answer is yes then please continue reading: Any chance some people are interested in offering time to perform a Wicket website makeover? Some questions for the site maintainers - Are the current web pages: 1. Generated from any tool via XLST or anything? 2. Served from a content management system? 3. Just static pages edited directly in HTML? 4. Served as a Wicket app? (would be awesome!) I guess the answer to these determines the quickest way possible to a refurbished website if Wicketeers agree that is appropriate. Could we hook together a simple system that actually uses a very simple Wicket app itself to host the pages? Eg., provide page content in some wiki style text format and have a simple Wicket page class that interprets this and outputs formatted content? Aside: We have actually built a content management system for editing/hosting websites using Wicket but it's proprietary and I don't think Apache would approve of an Apache site being served by a proprietary content management system so that's probably not an option. We don't mind hosting it if they didn't mind but I'm thinking that's not going to be approved. Regards, Chris
RE: Wicke website makeover time?
Wicket examples are in the same styling as the website so yes, the same logic applies to them also - actually probably even more so as they really are 'examples of what a wicket app might look like' - which is a bit sad when, with a bit of Bootstrap and nice fonts, they can look so much more awesome. I'll check out jekyllrb. Ideally if we can change the generator and leave the jekyll source largely untouched for phase 1 then we avoid the effort of porting any content over to a new input format. Maybe a phase 2 could look at switching to a different input format if jekyll has issues/limitations. Regards, Chris -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Wednesday, 12 November 2014 7:21 PM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? Hi, On Wed, Nov 12, 2014 at 9:45 AM, Chris Colman wrote: > Hi fellow wicketeers! > > We all know that Wicket has to be the most awesome and productive Java > UI framework around but I am worried when I point new clients to the > Wicket website because it's look and feel is possibly a little dated or > '2007ish style'. > > I feel like the look and feel of the Wicket website doesn't do justice > to the full awesomeness that we all know wicket has. > > We all know that, using the wicket Java UI framework it's possible to > create websites with *any* look and feel but unfortunately many clients > don't have this same technical awareness and see the website for Wicket, > a framework for building web applications in Java, and assume that the > Wicket website itself is an example of the type of webapp/website you'll > end up with if you build it with Wicket - which we all know is not the > case: we're building awesome AJAX enabled, modern, sexy Bootstrap > templated webapps in Wicket. > > A few years ago someone had produced a prototype of a refurbished Wicket > website that looked really quite nice but it never was deployed to the > live server for some reason. I guess you mean https://github.com/dashorst/wicket-site. > > These days I think most developers know that it's fairly easy to make a > great, modern looking website using one of the many Bootstrap > customizations (eg., Bootswatch). > > First question: > > Does anyone else think a wicket website makeover is overdue (or are most > people happy with the current look and feel)? > I do! But I am not capable of doing it myself because I am not an artist. I don't have this kind of imagination to create something pretty. Functional - yes, but not pretty :( Recently I've had a conversation with a client about this topic. (They use Wicket Bootstrap) Me (explaining why Wicket Bootstrap is not a module of Apache Wicket distro): Today Bootstrap is the hype. Tomorrow something else will be This is the main reason why WB hasn't been merged as a sub project of Apache Wicket itself. The client: Agreed, and I think the strategy of Wicket is fine for experienced web developers. However, for every experienced developer, I assume there are 10 novices trying out Wicket and if you don't steer novice users towards a HTML/CSS framework to use with Wicket to create great looking apps, most of them will be disappointed and wander off elsewhere. More or less he said the same as you ! But I think he meant Wicket Examples instead of http://wicket.apache.org/ > If the answer is yes then please continue reading: > > Any chance some people are interested in offering time to perform a > Wicket website makeover? > I'll be glad to help with infrastructure, testing, fixing issues, etc. ! > > Some questions for the site maintainers - > > > Are the current web pages: > 1. Generated from any tool via XLST or anything? > The code is hosted at https://svn.apache.org/repos/asf/wicket/common/site/trunk. We use http://jekyllrb.com/ to generate static HTML files. It is simple and fast. > 2. Served from a content management system? > No. > 3. Just static pages edited directly in HTML? > Yes. 4. Served as a Wicket app? (would be awesome!) > No. Apache Infrastructure team doesn't allow usage of dynamically generated stuff because this leads of the higher maintenance cost. > > I guess the answer to these determines the quickest way possible to a > refurbished website if Wicketeers agree that is appropriate. > > Could we hook together a simple system that actually uses a very simple > Wicket app itself to host the pages? Eg., provide page content in some > wiki style text format and have a simple Wicket page class that > interprets this and outputs formatted content? > No. See above. > > Aside: We have actually built a content management system for > editing/hosting websites
RE: Wicke website makeover time?
Some of those look very nice indeed. How were they created? It sounds like people have been toying with this for a long time. Perhaps it never happened because we wanted to go from the current site to mega awesome in one single step - which was always too much effort. I think a multi phase approach might have more chance of success - as I said in my immediate previous post if we could live with jekyll source for phase one (even though it may not be ideal) then we can keep most of the current content source 'as is' and simply choose a decent modern Bootstrap CSS template to re-render it in to deliver the best 'bang for buck' possible at this early stage. Or does Jekyll have a fairly fixed translator that provides little customizability? -Original Message- From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] Sent: Wednesday, 12 November 2014 8:58 PM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? Several attempts at a refresh have been done but they all strand in two things: - time to actually do something with a design that is received enthusiastically - copywriting the website, especially the front page For example I tend to doodle in keynote for ideas of a new web site look and my latest thing is actually going back to our roots (at http://wicket.sourceforge.net/1.2): http://imgur.com/D74s1dj http://imgur.com/UFxgSRI,jHawnst#0 http://imgur.com/UFxgSRI,jHawnst#1 I think it looks awesome but lack currently the time to actually do something more with it other than have it in keynote. There are some hurdles to consider: - website technology (currently jekyll, but asciidoctor might be a better future candidate, especially for the reference guide) - svn pub sub, I guess there's git pub sub but am not sure if/how that works - how to publish the site (currently generate, svn commit, but if guide is part of our build (to enable live, compiling examples) how does that integrate in the site workflow... Martijn On Wed, Nov 12, 2014 at 9:21 AM, Martin Grigorov wrote: > Hi, > > > On Wed, Nov 12, 2014 at 9:45 AM, Chris Colman > wrote: > >> Hi fellow wicketeers! >> >> We all know that Wicket has to be the most awesome and productive Java >> UI framework around but I am worried when I point new clients to the >> Wicket website because it's look and feel is possibly a little dated or >> '2007ish style'. >> >> I feel like the look and feel of the Wicket website doesn't do justice >> to the full awesomeness that we all know wicket has. >> >> We all know that, using the wicket Java UI framework it's possible to >> create websites with *any* look and feel but unfortunately many clients >> don't have this same technical awareness and see the website for Wicket, >> a framework for building web applications in Java, and assume that the >> Wicket website itself is an example of the type of webapp/website you'll >> end up with if you build it with Wicket - which we all know is not the >> case: we're building awesome AJAX enabled, modern, sexy Bootstrap >> templated webapps in Wicket. >> >> A few years ago someone had produced a prototype of a refurbished Wicket >> website that looked really quite nice but it never was deployed to the >> live server for some reason. > > > I guess you mean https://github.com/dashorst/wicket-site. > > >> >> These days I think most developers know that it's fairly easy to make a >> great, modern looking website using one of the many Bootstrap >> customizations (eg., Bootswatch). >> >> First question: >> >> Does anyone else think a wicket website makeover is overdue (or are most >> people happy with the current look and feel)? >> > > I do! > But I am not capable of doing it myself because I am not an artist. > I don't have this kind of imagination to create something pretty. > Functional - yes, but not pretty :( > > Recently I've had a conversation with a client about this topic. (They use > Wicket Bootstrap) > > Me (explaining why Wicket Bootstrap is not a module of Apache Wicket > distro): > > Today Bootstrap is the hype. Tomorrow something else will be > This is the main reason why WB hasn't been merged as a sub project of > Apache Wicket itself. > > > The client: > > Agreed, and I think the strategy of Wicket is fine for experienced web > developers. > > However, for every experienced developer, I assume there are 10 novices > trying out Wicket and if you don't steer novice users towards a HTML/CSS > framework to use with Wicket to create great looking apps, most of them > will be disappointed and wander off elsewhere. > > > More or less he s
RE: Wicke website makeover time?
This looks like it could be useful: http://jekyllbootstrap.com/ They have autowired all the necessary Liquid template stuff to make generation of a bootstrap styled site from jekyll source a breeze. Maybe it's worth having a play with it using the current wicket site's jekyll source? -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Wednesday, 12 November 2014 9:11 PM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? On Wed, Nov 12, 2014 at 11:58 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > Several attempts at a refresh have been done but they all strand in two > things: > > - time to actually do something with a design that is received > enthusiastically > - copywriting the website, especially the front page > > For example I tend to doodle in keynote for ideas of a new web site > look and my latest thing is actually going back to our roots (at > http://wicket.sourceforge.net/1.2): > > http://imgur.com/D74s1dj > http://imgur.com/UFxgSRI,jHawnst#0 > http://imgur.com/UFxgSRI,jHawnst#1 > > I think it looks awesome but lack currently the time to actually do > something more with it other than have it in keynote. > > There are some hurdles to consider: > - website technology (currently jekyll, but asciidoctor might be a > better future candidate, especially for the reference guide) > > - svn pub sub, I guess there's git pub sub but am not sure if/how that > works > There was a discussion at infra@ the other day about this: David Nalley (Infra team leader): In a word, no. Technically, I am sure we could build it, but we won't. We use svnpubsub to keep the ~250 websites we have to manage a relatively sane process. Moving some sites to git makes that far more complicated. --David On Mon, Nov 10, 2014 at 2:07 AM, Tomer Shiran wrote: > I have a follow-up question. Is it possible to use git to publish the > website as opposed to svn? We use git for the project's source code, so that > would be convenient. But this should not stop us. It is easy to create our own shell script that copies the Asciidoctor output to another folder (the site svn working directory) and commit it. We can add it to the release.sh script. - how to publish the site (currently generate, svn commit, but if > guide is part of our build (to enable live, compiling examples) how > does that integrate in the site workflow... > > Martijn > > > On Wed, Nov 12, 2014 at 9:21 AM, Martin Grigorov > wrote: > > Hi, > > > > > > On Wed, Nov 12, 2014 at 9:45 AM, Chris Colman < > chr...@stepaheadsoftware.com> > > wrote: > > > >> Hi fellow wicketeers! > >> > >> We all know that Wicket has to be the most awesome and productive Java > >> UI framework around but I am worried when I point new clients to the > >> Wicket website because it's look and feel is possibly a little dated or > >> '2007ish style'. > >> > >> I feel like the look and feel of the Wicket website doesn't do justice > >> to the full awesomeness that we all know wicket has. > >> > >> We all know that, using the wicket Java UI framework it's possible to > >> create websites with *any* look and feel but unfortunately many clients > >> don't have this same technical awareness and see the website for Wicket, > >> a framework for building web applications in Java, and assume that the > >> Wicket website itself is an example of the type of webapp/website you'll > >> end up with if you build it with Wicket - which we all know is not the > >> case: we're building awesome AJAX enabled, modern, sexy Bootstrap > >> templated webapps in Wicket. > >> > >> A few years ago someone had produced a prototype of a refurbished Wicket > >> website that looked really quite nice but it never was deployed to the > >> live server for some reason. > > > > > > I guess you mean https://github.com/dashorst/wicket-site. > > > > > >> > >> These days I think most developers know that it's fairly easy to make a > >> great, modern looking website using one of the many Bootstrap > >> customizations (eg., Bootswatch). > >> > >> First question: > >> > >> Does anyone else think a wicket website makeover is overdue (or are most > >> people happy with the current look and feel)? > >> > > > > I do! > > But I am not capable of doing it myself because I am not an artist. > > I don't have this kind of imagination to create something pretty. > > Functional - yes, but not pretty :(
RE: Wicke website makeover time?
>> I think a multi phase approach might have more chance of success - as I >> said in my immediate previous post if we could live with jekyll source >> for phase one (even though it may not be ideal) then we can keep most of >> the current content source 'as is' and simply choose a decent modern >> Bootstrap CSS template to re-render it in to deliver the best 'bang for >> buck' possible at this early stage. > >Bootstrap would be too standard and anonymous and would ultimately be >a ball and chain. A little .less and responsiveness can easily be >achieved without going bootstrap. IMHO standard and anonymous looks a lot better than retro late 1990s ;) Having said that, there are plenty of Bootstrap customization tools (Bootswatch etc.,) that would allow us to customize very quickly and so move well away from the standard and anonymous Bootstrap look and feel - I would never use the standard Bootstrap template without customization - it's too generic these days. While we could go "home grown" i.e. without the help of Bootstrap and do a little .less (or .sass) and responsiveness the use of Bootstrap's already awesome (tried and tested and working) responsiveness and it's cross browser compatibility (who wants to deal with issues like that in 2014?) could make this a very quick project. I know I don't have a lot of time to spare to make greenfield, home grown responsiveness that works across IE7+, FF, Chrome and Safari. So a quick project is a good project for me. If it ends up looking a lot more modern and sexy than the current site and it takes hours instead of weeks then I think it's going to happen. If we insist on not using a grid/CSS/JS template like Bootstrap and so make the effort measured in weeks instead of hours then I fear that the website will still have it's current look and feel in a years time. I don't think we'll be locked into Bootstrap anyway. If the translator uses bootstrap then the copy can remain Bootstrap free and easily moved to another CSS/JS library later if required. > >> Or does Jekyll have a fairly fixed translator that provides little >> customizability? > >Jekyll is fully customizable. It's just a translator from markdown to >HTML with templates and includes. > >Martijn > >- >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: Wicke website makeover time?
Yes, that looks very nice indeed. That's the sort of website I'd love my clients to see when I tell them I'm planning to build their 'next big thing' using Wicket. -Original Message- From: Guillaume Smet [mailto:guillaume.s...@gmail.com] Sent: Friday, 14 November 2014 11:50 PM To: users@wicket.apache.org Subject: Re: Wicke website makeover time? Hi, Personnally, I really liked what Martijn did here: http://people.apache.org/~dashorst/wicket-flat/ It's clean and has personnality. The only thing IMHO is that a one page design for this amount of information is perhaps a bit too much. -- Guillaume On Fri, Nov 14, 2014 at 1:14 PM, Chris Colman wrote: >>> I think a multi phase approach might have more chance of success - as > I >>> said in my immediate previous post if we could live with jekyll > source >>> for phase one (even though it may not be ideal) then we can keep most > of >>> the current content source 'as is' and simply choose a decent modern >>> Bootstrap CSS template to re-render it in to deliver the best 'bang > for >>> buck' possible at this early stage. >> >>Bootstrap would be too standard and anonymous and would ultimately be >>a ball and chain. A little .less and responsiveness can easily be >>achieved without going bootstrap. > > IMHO standard and anonymous looks a lot better than retro late 1990s ;) > > Having said that, there are plenty of Bootstrap customization tools > (Bootswatch etc.,) that would allow us to customize very quickly and so > move well away from the standard and anonymous Bootstrap look and feel - > I would never use the standard Bootstrap template without customization > - it's too generic these days. > > While we could go "home grown" i.e. without the help of Bootstrap and do > a little .less (or .sass) and responsiveness the use of Bootstrap's > already awesome (tried and tested and working) responsiveness and it's > cross browser compatibility (who wants to deal with issues like that in > 2014?) could make this a very quick project. > > I know I don't have a lot of time to spare to make greenfield, home > grown responsiveness that works across IE7+, FF, Chrome and Safari. > > So a quick project is a good project for me. If it ends up looking a lot > more modern and sexy than the current site and it takes hours instead of > weeks then I think it's going to happen. If we insist on not using a > grid/CSS/JS template like Bootstrap and so make the effort measured in > weeks instead of hours then I fear that the website will still have it's > current look and feel in a years time. > > I don't think we'll be locked into Bootstrap anyway. If the translator > uses bootstrap then the copy can remain Bootstrap free and easily moved > to another CSS/JS library later if required. > >> >>> Or does Jekyll have a fairly fixed translator that provides little >>> customizability? >> >>Jekyll is fully customizable. It's just a translator from markdown to >>HTML with templates and includes. >> >>Martijn >> >>- >>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
