Serving Wicket Resources from CDN (Announcement/Tutorial)
Hi all, I've just released a new version of wicketstuff-merged-resource to Maven Central. It supports serving wicket-mounted resources through CDNs using a pretty simple URL coding strategy (which may be used on its own too). This only works for CDNs that fetch the resources as users request them though, i.e. not those that require you to upload first. Amazon CloudFront would be such a CDN. For those interested: http://techblog.molindo.at/2011/03/serving-wicket-resources-from-cdn.html Download: http://repo1.maven.org/maven2/at/molindo/wicketstuff-merged-resources/3.1-alpha-1/ GibHub: https://github.com/molindo/wicketstuff-merged-resources Hope you like it. Cheers, Stefan
wicketstuff-merged-resources: New (much simpler) Version
Hi all, I just wanted to let you know that I've posted an article on the new version of wicketstuff-merged-resources: http://techblog.molindo.at/2009/09/wicketstuff-merged-resources-new-much-simpler-version.html For those that aren't aware of this small library: wicketstuff-merged-resources is a set of simple helper classes to improve Wicket interface loading performance. This is achieved with improved caching configuration and merging of shared resources without the need of touching any components (it's all done inside Application.init()). The initial code base was the outcome of Stefan Fussenegger's blog series called "Wicket Interface Speed-Up". (from Wicket Stuff Wiki: http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-merged-resources) Btw, if you're interested in serving Wicket-mounted resources from Amazon S3/CloudFront, it might be worth subscribing to my blog. I am planning a write-up on how to use wicketstuff-merged-resources to upload and mount resources to/from Amazon's CDN. Cheers, Stefan Fußenegger http://techblog.molindo.at/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicketstuff-merged-resources: New (much simpler) Version
Hi all, I just wanted to let you know that I've posted an article on the new version of wicketstuff-merged-resources: http://techblog.molindo.at/2009/09/wicketstuff-merged-resources-new-much-simpler-version.html For those that aren't aware of this small library: wicketstuff-merged-resources is a set of simple helper classes to improve Wicket interface loading performance. This is achieved with improved caching configuration and merging of shared resources without the need of touching any components (it's all done inside Application.init()). The initial code base was the outcome of Stefan Fussenegger's blog series called "Wicket Interface Speed-Up". (from Wicket Stuff Wiki: http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-merged-resources) Btw, if you're interested in serving Wicket-mounted resources from Amazon S3/CloudFront, it might be worth subscribing to my blog. I am planning a write-up on how to use wicketstuff-merged-resources to upload and mount resources to/from Amazon's CDN. Cheers, Stefan Fußenegger http://techblog.molindo.at/ (Sorry if this message appears multiple time - but I feel that the previous attempts to post to this list with another address didn't work) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Technologies to use with large scale Wicket application
want to give > users a choice of method for accepting payments. They can receive > payments via Google Checkout, PayPal, or their own merchant account. > If anyone knows of any tools that would help with this, please let me > know. Otherwise, I'll just use the APIs directly available from the > payment systems. I've already got Google Checkout integrated into > another project. > > OpenID > I want to be able to allow users to log in with an OpenID. I > understand Spring Security now has this built in. But there are other > ways to do it besides Spring. Has anyone integrated OpenID before, > and if so what tools did you use? > > Facebook Developer Program > Facebook Connect > I haven't really looked into these programs yet, but I'm looking for > ways to support Facebook users. It looks like I can get parts of our > application to run within facebook. But I'm also wanting to allow > facebook users to log into my application and access data and > information from FB. For instance, my hope is that making connections > with other users in my application can be simplified by utilizing the > connections the user has on FB. > > OpenSocial > This tool will help to create a social application platform that other > developers can build on top of, create widgets for, and so forth. > Also, this will allow my team to integrate our application into other > opensocial platforms. > > OAuth > To simplify authentication so I can allow access to my data from other > services. > > Terracotta > Never used it, but it looks good for clustering. I need to figure out > how to build this application in a way that I can run instances not > only locally, but all across the world if necessary. Thoughts? > > Scalability/Availability/Cloud Computing > Amazon EC2 Elastic Cloud > Amazon S3 storage > Amazon CloudFront > Joyent Accelerator > We will be hosting the application ourselves initially (perhaps in > xen, vbox, or openvz containers). But we want to build it in a way > that as it grows, we can easily launch new instances in the cloud. > And so we can easily expand our disk storage needs as we grow. And if > we get a lot of foreign users, we want to launch instances closer to > them, etc. However, I don't like having my application married to > Amazon and their APIs... There are so many questions to answer here, > and it is way off topic for Wicket. But if anyone has thoughts, > please let me know. > > jQuery > I've used this a lot and am familiar with it. > > ExtJS > Some of its components may be useful for my application. > > Thanks in advance! > Tauren > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Technologies-to-use-with-large-scale-Wicket-application-tp21447510p21497632.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes
My suggestions was to actually maintain a minimal JS api in the future. I don't believe that the very basic utility functions are going to change between minor versions. So it might be worth thinking about making this API official. The users would definitely benefit from it - and nobody would have to write a single line of code. It's just a suggestion, as I think it's at least worth considering. igor.vaynberg wrote: > > thats exactly the point. we do not maintain api compatibility of the > js code, not even between minor versions, so you should not use them > or depend on them. > > -igor > > On Thu, Jan 15, 2009 at 10:05 AM, Stefan Fußenegger > wrote: >> >> Even if they are for "wicket's internal use", documentation might be >> valuable, especially for (wicketstuff) developers who go deeper then >> regular >> users. Furthermore, having some basic JS utilities (with documented >> public >> API) coming with Wicket would make using Wicket even more fun. I'd bet >> that >> a lot of Wicket users implemented Wicket.$('id') or something similar on >> their own. And I'm not talking about a fully fledged JS framework or >> library, just some basic stuff to handle common tasks like the whole >> event >> stuff or some DOM manipulations. Basically just what's in place already >> but >> kept secret for "internal use only". >> >> Maybe that's a candidate for the Wicket 1.5 wishlist ... >> >> >> igor.vaynberg wrote: >>> >>> On Thu, Jan 15, 2009 at 9:11 AM, Stefan Fußenegger >>> wrote: >>>> >>>> I knew it was pseudo code. With "JS library" I meant the stuff >>>> contained >>>> in >>>> wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js. >>> >>> those are for wicket's internal use. dont touch :) >>> >>>> with replacing border, you meant the server-side concept of a Border, >>>> right? >>>> I was talking more of a html related concept (bad description, sorry), >>>> where >>>> a border is some markup surrounding some other markup. The later should >>>> be >>>> kept untouched by the update. I think it shouldn't be to difficult to >>>> get >>>> a >>>> DOM node by id, remove it or move it somewhere else temporarily, insert >>>> the >>>> ajax-retrieve stuff, move the DOM node back to where it was. If the >>>> implementation is as simple as this, it would be a feature worth >>>> adding, >>>> wouldn't it? >>> >>> javascript implementation is easy, it is the serverside declaration >>> and invocation that would be confusing. you are welcome to prototype >>> it if you want to pursue it further. >>> >>> -igor >>> >>>> >>>> Regards >>>> >>>> >>>> igor.vaynberg wrote: >>>>> >>>>> On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger >>>>> wrote: >>>>>> >>>>>> Thanks, I'll go for the suggested JS.Is there any documentation of >>>>>> the >>>>>> Wicket >>>>>> JavaScript library available somewhere? >>>>> >>>>> there is no wicket js library, what i gave you was pseudocode. >>>>> >>>>>> However, wouldn't be replacing borders (i.e. keeping parts of the >>>>>> hierarchy) >>>>>> be a nice feature? I'd add a ticket if you agree. >>>>> >>>>> you can replace borders already, the problem here relates to the >>>>> timing of client-server interaction. because you are validating while >>>>> the user is typing the serverside often gets the value that is out of >>>>> date since the user types faster then you can send requests to the >>>>> server. this means that when repainting the component on the >>>>> serverside there is a good chance you will repaint it with the wrong >>>>> value. >>>>> >>>>> currently there is no way to tell a form component to repaint but not >>>>> update its value attribute, and this is not always possible anyways. >>>>> >>>>> -igor >>>>> >>>>>> >>>>>> Regards, Stefan >>>>>> >>>>>> >>>>>> igor.vaynberg wrote: >>>>
Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes
Even if they are for "wicket's internal use", documentation might be valuable, especially for (wicketstuff) developers who go deeper then regular users. Furthermore, having some basic JS utilities (with documented public API) coming with Wicket would make using Wicket even more fun. I'd bet that a lot of Wicket users implemented Wicket.$('id') or something similar on their own. And I'm not talking about a fully fledged JS framework or library, just some basic stuff to handle common tasks like the whole event stuff or some DOM manipulations. Basically just what's in place already but kept secret for "internal use only". Maybe that's a candidate for the Wicket 1.5 wishlist ... igor.vaynberg wrote: > > On Thu, Jan 15, 2009 at 9:11 AM, Stefan Fußenegger > wrote: >> >> I knew it was pseudo code. With "JS library" I meant the stuff contained >> in >> wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js. > > those are for wicket's internal use. dont touch :) > >> with replacing border, you meant the server-side concept of a Border, >> right? >> I was talking more of a html related concept (bad description, sorry), >> where >> a border is some markup surrounding some other markup. The later should >> be >> kept untouched by the update. I think it shouldn't be to difficult to get >> a >> DOM node by id, remove it or move it somewhere else temporarily, insert >> the >> ajax-retrieve stuff, move the DOM node back to where it was. If the >> implementation is as simple as this, it would be a feature worth adding, >> wouldn't it? > > javascript implementation is easy, it is the serverside declaration > and invocation that would be confusing. you are welcome to prototype > it if you want to pursue it further. > > -igor > >> >> Regards >> >> >> igor.vaynberg wrote: >>> >>> On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger >>> wrote: >>>> >>>> Thanks, I'll go for the suggested JS.Is there any documentation of the >>>> Wicket >>>> JavaScript library available somewhere? >>> >>> there is no wicket js library, what i gave you was pseudocode. >>> >>>> However, wouldn't be replacing borders (i.e. keeping parts of the >>>> hierarchy) >>>> be a nice feature? I'd add a ticket if you agree. >>> >>> you can replace borders already, the problem here relates to the >>> timing of client-server interaction. because you are validating while >>> the user is typing the serverside often gets the value that is out of >>> date since the user types faster then you can send requests to the >>> server. this means that when repainting the component on the >>> serverside there is a good chance you will repaint it with the wrong >>> value. >>> >>> currently there is no way to tell a form component to repaint but not >>> update its value attribute, and this is not always possible anyways. >>> >>> -igor >>> >>>> >>>> Regards, Stefan >>>> >>>> >>>> igor.vaynberg wrote: >>>>> >>>>> the way to do this is to have the div be output there without >>>>> class="error" and to append the class to it via >>>>> ajaxrequesttarget.appendjavascript("$(divid).addclass('error');"); >>>>> >>>>> that way you do not need to repaint the input tag which is the >>>>> problematic part for your usecase. >>>>> >>>>> -igor >>>>> >>>>> On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> My HTML looks similar to this: >>>>>> >>>>>> Foo >>>>>> >>>>>> I want to validate the contents of the field as soon as the user >>>>>> starts >>>>>> typing. If there is an error, the html should become: >>>>>> >>>>>> There was an errorFoo>>>>> type="text" >>>>>> /> >>>>>> >>>>>> However, if I add the whole hierarchy to the AjaxRequestTarget, the >>>>>> changes >>>>>> in the text field get lost (Which results in quite weired typing >>>>>> behavior). >>>>>> >>>>>
Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes
I knew it was pseudo code. With "JS library" I meant the stuff contained in wicket-ajax.js, wicket-event.js, wicket-ajax-debug.js. with replacing border, you meant the server-side concept of a Border, right? I was talking more of a html related concept (bad description, sorry), where a border is some markup surrounding some other markup. The later should be kept untouched by the update. I think it shouldn't be to difficult to get a DOM node by id, remove it or move it somewhere else temporarily, insert the ajax-retrieve stuff, move the DOM node back to where it was. If the implementation is as simple as this, it would be a feature worth adding, wouldn't it? Regards igor.vaynberg wrote: > > On Thu, Jan 15, 2009 at 12:53 AM, Stefan Fußenegger > wrote: >> >> Thanks, I'll go for the suggested JS.Is there any documentation of the >> Wicket >> JavaScript library available somewhere? > > there is no wicket js library, what i gave you was pseudocode. > >> However, wouldn't be replacing borders (i.e. keeping parts of the >> hierarchy) >> be a nice feature? I'd add a ticket if you agree. > > you can replace borders already, the problem here relates to the > timing of client-server interaction. because you are validating while > the user is typing the serverside often gets the value that is out of > date since the user types faster then you can send requests to the > server. this means that when repainting the component on the > serverside there is a good chance you will repaint it with the wrong > value. > > currently there is no way to tell a form component to repaint but not > update its value attribute, and this is not always possible anyways. > > -igor > >> >> Regards, Stefan >> >> >> igor.vaynberg wrote: >>> >>> the way to do this is to have the div be output there without >>> class="error" and to append the class to it via >>> ajaxrequesttarget.appendjavascript("$(divid).addclass('error');"); >>> >>> that way you do not need to repaint the input tag which is the >>> problematic part for your usecase. >>> >>> -igor >>> >>> On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger >>> wrote: >>>> >>>> Hi, >>>> >>>> My HTML looks similar to this: >>>> >>>> Foo >>>> >>>> I want to validate the contents of the field as soon as the user starts >>>> typing. If there is an error, the html should become: >>>> >>>> There was an errorFoo>>> type="text" >>>> /> >>>> >>>> However, if I add the whole hierarchy to the AjaxRequestTarget, the >>>> changes >>>> in the text field get lost (Which results in quite weired typing >>>> behavior). >>>> >>>> Is it possible to skip components from being updated within another >>>> component? Might storing the value (prependJavascript), updating the >>>> whole >>>> hierarchy and writing back the stored value (appendJavascript) give >>>> satisfying results. >>>> >>>> What do you think? Any other ideas? >>>> >>>> Thanks, Stefan >>>> >>>> - >>>> --- >>>> Stefan Fußenegger >>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.html >>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21473620.html >> Sent from the
Re: Ajax-Update MarkupContaining containing FormComponent without loosing user changes
Thanks, I'll go for the suggested JS.Is there any documentation of the Wicket JavaScript library available somewhere? However, wouldn't be replacing borders (i.e. keeping parts of the hierarchy) be a nice feature? I'd add a ticket if you agree. Regards, Stefan igor.vaynberg wrote: > > the way to do this is to have the div be output there without > class="error" and to append the class to it via > ajaxrequesttarget.appendjavascript("$(divid).addclass('error');"); > > that way you do not need to repaint the input tag which is the > problematic part for your usecase. > > -igor > > On Tue, Jan 13, 2009 at 4:49 AM, Stefan Fußenegger > wrote: >> >> Hi, >> >> My HTML looks similar to this: >> >> Foo >> >> I want to validate the contents of the field as soon as the user starts >> typing. If there is an error, the html should become: >> >> There was an errorFoo> /> >> >> However, if I add the whole hierarchy to the AjaxRequestTarget, the >> changes >> in the text field get lost (Which results in quite weired typing >> behavior). >> >> Is it possible to skip components from being updated within another >> component? Might storing the value (prependJavascript), updating the >> whole >> hierarchy and writing back the stored value (appendJavascript) give >> satisfying results. >> >> What do you think? Any other ideas? >> >> Thanks, Stefan >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21473620.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Ajax-Update MarkupContaining containing FormComponent without loosing user changes
Hi, My HTML looks similar to this: Foo I want to validate the contents of the field as soon as the user starts typing. If there is an error, the html should become: There was an errorFoo However, if I add the whole hierarchy to the AjaxRequestTarget, the changes in the text field get lost (Which results in quite weired typing behavior). Is it possible to skip components from being updated within another component? Might storing the value (prependJavascript), updating the whole hierarchy and writing back the stored value (appendJavascript) give satisfying results. What do you think? Any other ideas? Thanks, Stefan - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Ajax-Update-MarkupContaining-containing-FormComponent-without-loosing-user-changes-tp21435127p21435127.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: code for DataGrid with vertical scrolling
I once started working on a component that used vertical scrolling. It was based on a GrowableListView (based on http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/), GrowableListView.java: http://pastie.org/345504 GrowableListView.html: http://pastie.org/345507 Might not be the cleanest or best code ever, but it used to work - if I remember correctly. This could be used to add columns to a single-row-table, where each table cell contains a ListView of items To use a table with the above code, call setItemTagName("td"); setContainerTagName("tr"); This table could than be scrolled with JS, e.g. with Dojo's dojox.fx.smoothScroll(). That's the part I didn't finish so far, though :) You'd probably be able to adapt the JS code found here: http://www.songtexte.com/songtext/johnny-cash/folsom-prison-blues-3d41577.html (see the "Videos" box in the right column) miro wrote: > > please point me for the code with data grid vertical scrolling component. > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/code-for-DataGrid-with-vertical-scrolling-tp21112343p21144910.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dojo 1.1 integration available from wicketstuff
Hi Emanuele, I don't plan to support additional components myself - especially not problems that seem to be caused by Dojo only. wicketstuff-dojo-1.1 is mainly meant to ease the integration of Dojo into Wicket (i.e. to provide the infrastructure like custom builds, packaging as jar files, configuration of Dojo as part of a Wicket application, mounting resources and the like). In the future, there might be more and more components available out of the box. However, at the moment I don't have plans - or time - to add more components than those already included (animations, toaster widget, drag and drop and cometd support) If you've built a Wicket component based on wicketstuff-dojo-1.1, you're welcome to contribute your code. If you want to contribute but don't know how, I'd be happy to get you started. Merry Christmas, Stefan Emanuele Gesuato-2 wrote: > > Stefan Fußenegger wrote: >> There's now a little bit of documentation online: >> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-dojo-1.1 >> >> Cheers, Stefan >> > > Hi, > > First of all, good job. > > Is there any plan to support the dojo context menu ? :-) > > We are using it but we've got several warnings with some deprecation > calls on the html document in development that are quite annoying. > Also if i have different context menu in the same page and if these > context menu has submenus, the submenus are sharing the same instance of > the content component. > > Example: > If i have menuA and menuB in two tables, tableA and tableB. If i right > click on menuA or menuB in the java code i see that the referenced > component is always on tableB. This only happens in the voices of the > menu that are in a submenu. > > > > Thanks for any help, > Emanuele > > > ----- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p21144111.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dojo 1.1 integration available from wicketstuff
There's now a little bit of documentation online: http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-dojo-1.1 Cheers, Stefan Stefan Fußenegger wrote: > > Hi folks, > > I just shared a new project called wicketstuff-dojo-1.1 [1], an > integration of the Dojo JavaScript toolkit [2] into Wicket. This project > is based on wicketstuff-dojo [3] and wicketstuff-push [4] (both based on > dojo 0.4). However, not all of the components from wicketstuff-dojo have > been ported to the new dojo version (but feel free to do so). > > Currently, there is no documentation available. I'll add some info to the > wicketstuff wiki next week. In the meantime, (really) early adopters can > check it out for review. To build the project, check it out and run `mvn > clean install`. To build a custom dojo distribution, place your > .profile.js (e.g. foobar.profile.js) in buildDojo/custom-profile/ > and run `mvn -Ddojo.profile= clean install`. In your project pom, > add > > > org.wicketstuff > wicketstuff-dojo-1.1 > 1.3.5-standard-SNAPSHOT > > > or, for the custom profile > > > org.wicketstuff > wicketstuff-dojo-1.1 > 1.3.5--SNAPSHOT > > > (Not sure if this versioning strategy is the best choice, but it makes it > quite easy to use different custom profiles for different projects) > > Looking forward to your feedback! > > Regards, Stefan > > [1] > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-dojo-1.1/ > [2] http://dojotoolkit.org/ > [3] http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Dojo > [4] > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p21069750.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets
Hi Igor, thanks for implementing this minimal version. i totally agree with your reasoning. Is there any chance though that this goes into 1.3 branch as well? I'd really appreciate that. you mentioned that you implemented such a repeater yourself. didn't you use any navigation or did you write that yourself? just wondering. shall i open a ticket against 1.5 to track this issue/enhancement? best regards, stefan igor.vaynberg wrote: > > On Thu, Nov 27, 2008 at 12:46 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> I don't think IDataProvider is only about databases. > > you started off with your core assumption being wrong. idataprovider > was written exclusively for accessing databases. my thinking, at the > time, was that 99% of people use wicket to build applications that > access databases, and i dare say it was a good guess because in its ~3 > years of existence only a handful of people had a problem with the way > it works. > >> There are other data >> sources and some return the total amount and the desired subset at the >> same >> time (Lucene as a famous example). Such data sources would really benefit >> of >> a single-query-approach. > > i am not disputing this fact. i am simply saying that we are not going > to fix this right now because this is not a bug. you are trying to use > the components for something they were not designed to be used. in 1.5 > we may address this. > >> I faced this issue myself in a search (read Lucene) >> centered application. I successfully went down the road of implementing a >> custom repeater. > > i had to do the same myself. > >> But when the repeater was working as desired, I figured out >> that PagingNavigationLink is the real showstopper, not IDataProvider (see >> my >> JIRA comment [0]). The fix would be rather trivial, as >> PagingNavigationLink >> is doing something it needn't do (checking the requested page against the >> valid range of pages). >> >> Let me answer 2 possible questions in advance: >> >> Q: Why is this check in PagingNavigationLink a problem? >> A: Obviously, you can't fetch size and data as long as the page isn't >> known. > > the check is there because we code defensively. we do not assume that > every implementation of ipageable will cull the number when you call > setcurrentpage(x). > >> Q: How would a custom repeater that fetches data and size at the same >> tame >> handle invalid (out of range) pages? >> A: Out of range pages will return the size and an empty dataset. In this >> case, the repeater would change the page number to the last valid and do >> a >> second query. Yeah, two queries again. But this should only happen rarely >> though. > > this will change the existing behavior. if you are on page 5 and click > page 10 (which happens to not exist) you would end up back on 5 with > your suggestion where as currently you would properly end up on 9. > > looking at WICKET-1784, i extracted the code you want into an > overridable int cullPageNumber(int x). so feel free to subclass the > link and override that to return x without any extra checks. > > we may properly fix this in 1.5, but for right now this is too big a > refactor because it changes the basic assumptions with which the code > was written. > > -igor > >> >> Best regards, Stefan >> >> [0] >> https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12651278#action_12651278 >> >> >> igor.vaynberg wrote: >>> >>> On Wed, Nov 26, 2008 at 9:32 AM, Wayne Pope >>> <[EMAIL PROTECTED]> wrote: >>>>>so you think pushing all that extra data over the network is actually >>>>>more efficient then doing another query wtf. >>>> The point is I'd rather avoid 2 calls where 1 will do. >>>> AbstractPageableView >>>> will do fine I believe. >>> >>> the number of calls itself is meaningless, i dont comprehend why >>> people have a hard time understanding this simple fact. >>> >>> if you have one call that takes 1000ms and ten calls that each take >>> 10ms you should concentrate on the one call that takes a long time >>> rather then eliminating all ten 10ms calls which only saves you 100ms. >>> if you can optimize the 1000ms and shave off 20% then your eleven >>> calls are still faster then the one call. >>> >>> and since connection pools have been inventind many years ago there is >>> no more overhead of establishing network connections, just push
Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets
ing a significant chunk of >>> processing time in the database server? to the point where eliminating >>> it will actually reduce enough load on the database to increase your >>> throughput? >>> >>> -igor >>> >>> > >>> > Wayne >>> > >>> > >>> > On Wed, Nov 26, 2008 at 5:58 PM, Igor Vaynberg >>> <[EMAIL PROTECTED] >>> >wrote: >>> > >>> >> On Wed, Nov 26, 2008 at 7:32 AM, Wayne Pope >>> >> <[EMAIL PROTECTED]> wrote: >>> >> > I'm sure I must be missing something still, as I can't beleive that >>> we >>> >> need >>> >> > to either a) load the whole data set >>> >> >>> >> what? why would you ever load the whole dataset? >>> >> >>> >> b) call count on the Db , then load in >>> >> > the iterator mehod. Thats going to kill the database in prod (or >>> really >>> >> not >>> >> > help.) >>> >> >>> >> yeah. because select count() queries are the most expensive queries >>> >> you can run on the database. you are right, its totally going to kill >>> >> it. you know how all those sites on the internet that have a pager >>> >> above the pageable view that shows you the number of the last >>> >> available page...you know how those work without doing a select >>> >> count()? >>> >> >>> >> -igor >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> > >>> >> > On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer < >>> [EMAIL PROTECTED] >>> >> >wrote: >>> >> > >>> >> >> >>> >> >> have a look at https://issues.apache.org/jira/browse/WICKET-1784 >>> >> >> >>> >> >> >>> >> >> Wayne Pope-2 wrote: >>> >> >> > >>> >> >> > Ok, >>> >> >> > >>> >> >> > I was just having a bit of code clean up and I realized that in >>> our >>> >> >> > IDataProviders we are loading all rows for a given dataset. >>> >> >> > So looking at the iterator method I see we can limit the result >>> (and >>> >> the >>> >> >> > offset). Great I thought - however I see that that the size() >>> method >>> >> is >>> >> >> > called as part of the getViewSize() in the AbstractPageableView. >>> Thus >>> >> I >>> >> >> > need >>> >> >> > to call the database here to figure out the size. >>> >> >> > >>> >> >> > Am I doing sonething wrong or have I got to hit the database >>> twice >>> for >>> >> >> > each >>> >> >> > DataProvider render. >>> >> >> > >>> >> >> > Obvously I don't want to hard code a size. Is there any other >>> way ? >>> >> >> > >>> >> >> > Thanks >>> >> >> > Wayne >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> >>> >> >> - >>> >> >> Michael Sparer >>> >> >> http://talk-on-tech.blogspot.com >>> >> >> -- >>> >> >> View this message in context: >>> >> >> >>> >> >>> http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20702476.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] >>> >> >>> >> >>> > >>> >>> - >>> 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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20715382.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicketstuff-push is over, wickestuff-dojo-1.1 is born ???
see http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-to20625220.html Michael Sparer wrote: > > Hi Julien, > > we're doing our last tests today and tomorrow and will put > wicketstuff-dojo-1.1 into production by Monday. If no issues arise, we'll > share it as a wicketstuff project next week. Please note that so far, we > only ported some components to 1.1. (includes wiper, slider, drag and drop > and cometd). We're also making extensive use of cometd, which is quite a > bit better than in dojo 0.4 by the way, and it is also included in the > wicketstuff-dojo-1.1 project then. Then it's your turn to give > recommendations, improvements and, most important, help to get the same > functionality working for 1.1. > > as for the corrupted push project: rodolfo made some changes, so I don't > know what's going on there. A version of wicketstuff-push before rodolfo > started with the makeover is available as a branch. Just check out > wicketstuff's branches, if you can't wait till next week. > > regards, > Michael > > > julien Graglia wrote: >> >> Hi, >> I have read some posts (1) that seems to say that wicketstuff-push will >> be replaced by a new wicketstuff-dojo-1.1 artifact. >> >> The post says that this artifact is in a private SVN repo, but will be >> available "shortly".. >> >> Do you have any informations about that? >> >> I need to do reverse ajax with wicket (cometd...) ie. push event from a >> server thread at the server initiative. It works with an old (rev 4245) >> version of wicketstuff-push. The trunk seems "corrupted" : a "dojo" >> folder is missing.. >> >> >> >> 1 : http://www.nabble.com/New-wicketstuff-dojo-project-td19070145.html >> -- >> Julien Graglia >> NetCeler >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/wicketstuff-push-is-over%2C-wickestuff-dojo-1.1-is-born-tp20356751p20625246.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]
Dojo 1.1 integration available from wicketstuff
Hi folks, I just shared a new project called wicketstuff-dojo-1.1 [1], an integration of the Dojo JavaScript toolkit [2] into Wicket. This project is based on wicketstuff-dojo [3] and wicketstuff-push [4] (both based on dojo 0.4). However, not all of the components from wicketstuff-dojo have been ported to the new dojo version (but feel free to do so). Currently, there is no documentation available. I'll add some info to the wicketstuff wiki next week. In the meantime, (really) early adopters can check it out for review. To build the project, check it out and run `mvn clean install`. To build a custom dojo distribution, place your .profile.js (e.g. foobar.profile.js) in buildDojo/custom-profile/ and run `mvn -Ddojo.profile= clean install`. In your project pom, add org.wicketstuff wicketstuff-dojo-1.1 1.3.5-standard-SNAPSHOT or, for the custom profile org.wicketstuff wicketstuff-dojo-1.1 1.3.5--SNAPSHOT (Not sure if this versioning strategy is the best choice, but it makes it quite easy to use different custom profiles for different projects) Looking forward to your feedback! Regards, Stefan [1] https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-dojo-1.1/ [2] http://dojotoolkit.org/ [3] http://wicketstuff.org/confluence/display/STUFFWIKI/WicketStuff+Dojo [4] https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Dojo-1.1-integration-available-from-wicketstuff-tp20625220p20625220.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxFallbackButton: inconsistend submit order
https://issues.apache.org/jira/browse/WICKET-1894 btw: 1.3.5 is still in the "unreleased versions" section regards igor.vaynberg wrote: > > this sounds like a bug, please file a jira report > > -igor > > On Thu, Oct 23, 2008 at 6:47 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> Hi folks, >> >> I just stumbled upon a problem with a Form containing a nested Form and >> two >> AjaxFallbackButtons (submit and preview). I need to implement different >> onSubmit() behavior of the nested Form depending on the clicked button. >> >> The order of onSubmit() calls is: >> >> without JS: >> - AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form) >> - OuterForm.onSubmit() // not used >> - Inner Form.onSubmit() >> >> with JS: >> - Inner Form.onSubmit() >> - OuterForm.onSubmit() // not used >> - AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form) >> >> With JS, it is therefore not possible to determine which button was >> clicked >> from inside a form's onSubmit() method. >> >> Is this a (known) bug? >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/AjaxFallbackButton%3A-inconsistend-submit-order-tp20131329p20131329.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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/AjaxFallbackButton%3A-inconsistend-submit-order-tp20131329p20145832.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]
AjaxFallbackButton: inconsistend submit order
Hi folks, I just stumbled upon a problem with a Form containing a nested Form and two AjaxFallbackButtons (submit and preview). I need to implement different onSubmit() behavior of the nested Form depending on the clicked button. The order of onSubmit() calls is: without JS: - AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form) - OuterForm.onSubmit() // not used - Inner Form.onSubmit() with JS: - Inner Form.onSubmit() - OuterForm.onSubmit() // not used - AjaxFallbackButton.onSubmit(AjaxRequestTarget,Form) With JS, it is therefore not possible to determine which button was clicked from inside a form's onSubmit() method. Is this a (known) bug? - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/AjaxFallbackButton%3A-inconsistend-submit-order-tp20131329p20131329.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
wicketstuff-merged-resources is now available in JIRA: http://wicketstuff.org/jira/browse/WMR and from wicketstuff maven repo: wicket-snaps http://wicketstuff.org/maven/repository true true org.wicketstuff wicketstuff-merged-resources 1.3.4-SNAPSHOT i am also going to add a short wiki page at wicketstuff.org regards, Stefan Jörn Zaefferer-2 wrote: > > Good point, I forgot that wicketstuff has its own JIRA installation. > Though the entry for the project is missing. Let me know once its > there, and I'll create the report. > > Jörn > > On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: >> why don't you open up an issue in JIRA? >> >> >> Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer: >> >>> Here is a first patch for the RevisionVersionProvider: >>> >>> Index: >>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>> === >>> --- >>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>>(revision >>> 4147) >>> +++ >>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>>(working >>> copy) >>> @@ -15,7 +15,7 @@ >>> >>>public int getVersion(final Class scope, final String >>> fileName) >>> throws VersionException { >>>final String file = getResourcePath(scope, fileName); >>> - final InputStream in = >>> ClassLoader.getSystemResourceAsStream(file); >>> + final InputStream in = >>> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file); >>>if (in == null) { >>>throw new VersionException(scope, fileName, >>> "can't >>> find " + file); >>>} >>> >>> >>> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it >>> always returned null for classpath resources. Using the >>> RevisionVersionProvider classloader works fine. >>> >>> Let me know where I should post further patches etc. >>> >>> Jörn >>> >>> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> Code is now available through wicketsuff: >>>> >>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ >>>> wicketstuff-merged-resources and >>>> >>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ >>>> wicketstuff-merged-resources-examples >>>> >>>> Now I want to make it available through >>>> http://wicketstuff.org/maven/repository/. I therefore registered at >>>> wicketstuff.org/teamcity (sfussenegger). What's next? >>>> >>>> >>>> Stefan Fußenegger wrote: >>>>> >>>>> I just finished the 4th and last entry of my series "Wicket Interface >>>>> Speed-Up" on my blog. To give a short summary: I investigated one of >>>>> my >>>>> apps with YSlow and started optimizing it's interface rendering speed >>>>> [1]. >>>>> Especially Wicket's way of handling resources, i.e. JS and CSS files, >>>>> causes interfaces to load rather slowly. In my articles, I explain how >>>>> to >>>>> modify the cache interval [2], how to mount resources with a version >>>>> (e.g. >>>>> /css/all-1234.css) in order to use aggressive client-side caching >>>>> (e.g. >>>>> resources expire after a year) [3]. Finally, I show how to merge >>>>> resources >>>>> at application startup (using a class classed MergedResourceStream) to >>>>> reduce the number of resources a client has to download [4], including >>>>> code). I was able to increase interface loading times considerably, so >>>>> it's surely worth a look. >>>>> >>>>> I feel that it would also be worth to discuss, whether this work could >>>>> be >>>>> part of upcoming Wicket versions. For the tim
Re: Discussion on "Wicket Interface Speed-Up"
just applied your patch could somebody please create wicketstuff-merged-resources in JIRA and teamcity? Jörn Zaefferer-2 wrote: > > Here is a first patch for the RevisionVersionProvider: > > Index: > src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java > === > --- > src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java > (revision > 4147) > +++ > src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java > (working > copy) > @@ -15,7 +15,7 @@ > > public int getVersion(final Class scope, final String fileName) > throws VersionException { > final String file = getResourcePath(scope, fileName); > - final InputStream in = > ClassLoader.getSystemResourceAsStream(file); > + final InputStream in = > RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file); > if (in == null) { > throw new VersionException(scope, fileName, "can't find > " + file); > } > > > ClassLoader.getSystemResourceAsStream in my deployment enviroment, it > always returned null for classpath resources. Using the > RevisionVersionProvider classloader works fine. > > Let me know where I should post further patches etc. > > Jörn > > On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> Code is now available through wicketsuff: >> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ >> wicketstuff-merged-resources and >> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ >> wicketstuff-merged-resources-examples >> >> Now I want to make it available through >> http://wicketstuff.org/maven/repository/. I therefore registered at >> wicketstuff.org/teamcity (sfussenegger). What's next? >> >> >> Stefan Fußenegger wrote: >>> >>> I just finished the 4th and last entry of my series "Wicket Interface >>> Speed-Up" on my blog. To give a short summary: I investigated one of my >>> apps with YSlow and started optimizing it's interface rendering speed >>> [1]. >>> Especially Wicket's way of handling resources, i.e. JS and CSS files, >>> causes interfaces to load rather slowly. In my articles, I explain how >>> to >>> modify the cache interval [2], how to mount resources with a version >>> (e.g. >>> /css/all-1234.css) in order to use aggressive client-side caching (e.g. >>> resources expire after a year) [3]. Finally, I show how to merge >>> resources >>> at application startup (using a class classed MergedResourceStream) to >>> reduce the number of resources a client has to download [4], including >>> code). I was able to increase interface loading times considerably, so >>> it's surely worth a look. >>> >>> I feel that it would also be worth to discuss, whether this work could >>> be >>> part of upcoming Wicket versions. For the time being I'd like to make >>> the >>> code attached to [4] a wicketstuff project - sfussenegger needs commit >>> access ;) - and wait for your feedback. >>> >>> The links: >>> [1] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >>> Wicket Interface Speed-Up >>> [2] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers >>> [3] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >>> Wicket Interface Speed-Up: Caching Resources Forever >>> [4] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html >>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >>> >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.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] >> >> > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19218353.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
Code is now available through wicketsuff: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ wicketstuff-merged-resources and https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ wicketstuff-merged-resources-examples Now I want to make it available through http://wicketstuff.org/maven/repository/. I therefore registered at wicketstuff.org/teamcity (sfussenegger). What's next? Stefan Fußenegger wrote: > > I just finished the 4th and last entry of my series "Wicket Interface > Speed-Up" on my blog. To give a short summary: I investigated one of my > apps with YSlow and started optimizing it's interface rendering speed [1]. > Especially Wicket's way of handling resources, i.e. JS and CSS files, > causes interfaces to load rather slowly. In my articles, I explain how to > modify the cache interval [2], how to mount resources with a version (e.g. > /css/all-1234.css) in order to use aggressive client-side caching (e.g. > resources expire after a year) [3]. Finally, I show how to merge resources > at application startup (using a class classed MergedResourceStream) to > reduce the number of resources a client has to download [4], including > code). I was able to increase interface loading times considerably, so > it's surely worth a look. > > I feel that it would also be worth to discuss, whether this work could be > part of upcoming Wicket versions. For the time being I'd like to make the > code attached to [4] a wicketstuff project - sfussenegger needs commit > access ;) - and wait for your feedback. > > The links: > [1] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html > Wicket Interface Speed-Up > [2] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers > [3] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html > Wicket Interface Speed-Up: Caching Resources Forever > [4] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html > Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
Sounds promising ... and little mysterious ;) Any concrete plans/ideas so far? Matej Knopp-2 wrote: > > On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl <[EMAIL PROTECTED]> wrote: >> I totally agree that having the version in the filename and not in the >> query >> string will be a-lot-better. >> >> Just wanted to point you to that option so you can include it in your >> excellent analysis on caching *thanks* :-) >> >> People can use that option right now and get a more decent version later >> (e.g. your versioned resource filenames, which is the *correct* way) >> >> Resources need some more love in wicket 1.5 - full ack! >> > And they are going to get it :) Resources are going to be much simpler > in 1.5 - current code is too tangled and ambiguous. > > -Matej >> Cheers >> Peter >> >> >> Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger: >> >>> >>> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this >>> option. >>> However, changing filename instead of using query string has certain >>> advantages, see >>> >>> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ >>> >>> Furthermore, setting this option does not effect expires or >>> cache-control >>> headers. still only one hour, which is far from being aggressive. If you >>> want to change that, you'll still have to explicitly mount all resources >>> with your desired cache duration. >>> >>> Johan suggested (comment on >>> >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >>> my second article ) "what i can do is make it a setting: >>> IResourceSettings.getResourceCacheDuration()". If such a setting is >>> available, using >>> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) >>> would >>> make more sense. >>> >>> I still think though that this isn't enough and resources should get a >>> focus >>> in upcoming wicket versions. Some might argue, that resources shouldn't >>> be >>> served by Wicket at all, but I really don't like to use proxies, CDNs or >>> whatever voodoo for low traffic web sites: server-side performance isn't >>> an >>> issue there while client-side performance is. >>> >>> regards >>> >>> >>> Peter Ertl wrote: >>>> >>>> That's not true. >>>> >>>> this settings will generate urls like: >>>> >>>> /resources/[package+class]/javascript.js?lm=[lastmodified] >>>> >>>> read it again : "add Last Modified Time To Resource Reference Url" >>>> >>>>>> getApplication >>>>>> ().getResourceSettings >>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >>>> >>>> It will not sent the "LastModified" header as you think. >>>> >>>> So whenever the resource changes the url changes, too. >>>> >>>> Try it out and see :-) >>>> >>>> I did test it in Firefox. There will be no "IfModified" requests from >>>> the browser. >>>> >>>> Everything will be completely cached in the browser until the resource >>>> has changed. >>>> >>>> Cheers >>>> Peter >>>> >>>> >>>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: >>>> >>>>> >>>>> honestly, no, I didn't. however, using last modified times still >>>>> results in >>>>> an HTTP request and a "304 Not Modified" reply. better than nothing, >>>>> but >>>>> client-side caching is still preferable. >>>>> >>>>> regards >>>>> >>>>> >>>>> Peter Ertl wrote: >>>>>> >>>>>> @stefan: did you take into account >>>>>> >>>>>> >>>>>> getApplication >>>>>> ().getResourceSettings >>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >>>>>> >>>>>> Cheers >>>>>> Peter >>>>>> >>>>>> >>>>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: >>>>>> >>>>>>&g
Re: Discussion on "Wicket Interface Speed-Up"
I would love to see an approach where Wicket itself tries to determine a version. If a version is available, wicket would than add it to the filename and use an aggressive caching duration, e.g. 1 year. (no version, no caching) Additionally, what I currently don't like is that resource creation isn't flexible at all. The current approach (ResourceReference.newResource() called in ResourceReference.bind(Application) if resource isn't already bound) doesn't allow to change default resources, as one can't change the used ResourceReference type. I'd suggest - just thinking aloud right now - to change the current implementation to either Application.get().getResourceFactory().newResource(ResourceReference) instead of ResourceReference.newResource() or to make the ResourceReference type used within HeaderContributor.for...(..) changeable: response.renderJavascriptReference(new JavascriptResourceReference(scope, path)); // current response.renderJavascriptReference(Application.get().getResourceFactory().newJavascriptResourceReference(scope, path)); both approaches would allow to customize resource creation. regards Johan Compagner wrote: > > I thing we should look at what that append to url does, because i dont > like the query string either, i also rather have it in the url path > itself. > > Also such a resource cache duration can be added. But i also rather > have it configured by resoure(reference) like > > HeaderContributor.getCSSResourceReference('my.css',cachetime,urlmod) > > Johan > > On 8/29/08, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this >> option. >> However, changing filename instead of using query string has certain >> advantages, see >> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ >> >> Furthermore, setting this option does not effect expires or cache-control >> headers. still only one hour, which is far from being aggressive. If you >> want to change that, you'll still have to explicitly mount all resources >> with your desired cache duration. >> >> Johan suggested (comment on >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> my second article ) "what i can do is make it a setting: >> IResourceSettings.getResourceCacheDuration()". If such a setting is >> available, using >> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) >> would >> make more sense. >> >> I still think though that this isn't enough and resources should get a >> focus >> in upcoming wicket versions. Some might argue, that resources shouldn't >> be >> served by Wicket at all, but I really don't like to use proxies, CDNs or >> whatever voodoo for low traffic web sites: server-side performance isn't >> an >> issue there while client-side performance is. >> >> regards >> >> >> Peter Ertl wrote: >>> >>> That's not true. >>> >>> this settings will generate urls like: >>> >>>/resources/[package+class]/javascript.js?lm=[lastmodified] >>> >>> read it again : "add Last Modified Time To Resource Reference Url" >>> >>>>> getApplication >>>>> ().getResourceSettings >>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >>> >>> It will not sent the "LastModified" header as you think. >>> >>> So whenever the resource changes the url changes, too. >>> >>> Try it out and see :-) >>> >>> I did test it in Firefox. There will be no "IfModified" requests from >>> the browser. >>> >>> Everything will be completely cached in the browser until the resource >>> has changed. >>> >>> Cheers >>> Peter >>> >>> >>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: >>> >>>> >>>> honestly, no, I didn't. however, using last modified times still >>>> results in >>>> an HTTP request and a "304 Not Modified" reply. better than nothing, >>>> but >>>> client-side caching is still preferable. >>>> >>>> regards >>>> >>>> >>>> Peter Ertl wrote: >>>>> >>>>> @stefan: did you take into account >>>>> >>>>> >>>>> getApplication >>>>> ().getResourceSettings >>>>> ().setAddLastMo
Re: Discussion on "Wicket Interface Speed-Up"
Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option. However, changing filename instead of using query string has certain advantages, see http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ Furthermore, setting this option does not effect expires or cache-control headers. still only one hour, which is far from being aggressive. If you want to change that, you'll still have to explicitly mount all resources with your desired cache duration. Johan suggested (comment on http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html my second article ) "what i can do is make it a setting: IResourceSettings.getResourceCacheDuration()". If such a setting is available, using IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would make more sense. I still think though that this isn't enough and resources should get a focus in upcoming wicket versions. Some might argue, that resources shouldn't be served by Wicket at all, but I really don't like to use proxies, CDNs or whatever voodoo for low traffic web sites: server-side performance isn't an issue there while client-side performance is. regards Peter Ertl wrote: > > That's not true. > > this settings will generate urls like: > >/resources/[package+class]/javascript.js?lm=[lastmodified] > > read it again : "add Last Modified Time To Resource Reference Url" > >>> getApplication >>> ().getResourceSettings >>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? > > It will not sent the "LastModified" header as you think. > > So whenever the resource changes the url changes, too. > > Try it out and see :-) > > I did test it in Firefox. There will be no "IfModified" requests from > the browser. > > Everything will be completely cached in the browser until the resource > has changed. > > Cheers > Peter > > > Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: > >> >> honestly, no, I didn't. however, using last modified times still >> results in >> an HTTP request and a "304 Not Modified" reply. better than nothing, >> but >> client-side caching is still preferable. >> >> regards >> >> >> Peter Ertl wrote: >>> >>> @stefan: did you take into account >>> >>> >>> getApplication >>> ().getResourceSettings >>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >>> >>> Cheers >>> Peter >>> >>> >>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: >>> >>>> sfussenegger now has access to wicketstuff... >>>> >>>> i dont know which parts should go into wicket itself, i can tell you >>>> that the part where you merge the files by listing them out >>>> upfront is >>>> probably not going to make it in because it breaks encapsulation... >>>> >>>> -igor >>>> >>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> I just finished the 4th and last entry of my series "Wicket >>>>> Interface >>>>> Speed-Up" on my blog. To give a short summary: I investigated one >>>>> of my apps >>>>> with YSlow and started optimizing it's interface rendering speed >>>>> [1]. >>>>> Especially Wicket's way of handling resources, i.e. JS and CSS >>>>> files, causes >>>>> interfaces to load rather slowly. In my articles, I explain how to >>>>> modify >>>>> the cache interval [2], how to mount resources with a version (e.g. >>>>> /css/all-1234.css) in order to use aggressive client-side caching >>>>> (e.g. >>>>> resources expire after a year) [3]. Finally, I show how to merge >>>>> resources >>>>> at application startup (using a class classed MergedResourceStream) >>>>> to >>>>> reduce the number of resources a client has to download [4], >>>>> including >>>>> code). I was able to increase interface loading times considerably, >>>>> so it's >>>>> surely worth a look. >>>>> >>>>> I feel that it would also be worth to discuss, whether this work >>>>> could be >>>>> part of upcoming Wicket versions. For the time being I'd like to >>>>> make the >>>>
Re: Discussion on "Wicket Interface Speed-Up"
you're right with the encapsulation, but i feel that resource versioning (and aggressive client side caching) could be a nice addition to wicket. but maybe sombody can think of another way to reduce (merge) resources without breaking encapsulation ... btw, resource versioning also works with wicket-ajax.js and wicket-event.js: protected void init() { final String version = getFrameworkSettings().getVersion(); final String suffix = ("n/a".equals(version) ? "" : "-" + version) + ".js"; getSharedResources().add(WicketAjaxReference.INSTANCE.getName(), getResourceReference(WicketAjaxReference.class, "wicket-ajax.js").getResource()); mountSharedResourceWithCaching("/scripts/wicket-ajax" + suffix, WicketAjaxReference.INSTANCE.getSharedResourceKey()); getSharedResources().add(WicketEventReference.INSTANCE.getName(), getResourceReference(WicketEventReference.class, "wicket-event.js").getResource()); mountSharedResourceWithCaching("/scripts/wicket-event" + suffix, WicketEventReference.INSTANCE.getSharedResourceKey()); } // it's getting dirty ... protected void mountSharedResourceWithCaching(final String path, final String resourceKey) { mount(new SharedResourceRequestTargetUrlCodingStrategy(path, resourceKey) { public IRequestTarget decode(final RequestParameters requestParameters) { final SharedResourceRequestTarget t = (SharedResourceRequestTarget) super.decode(requestParameters); if (t != null) { // wrap target return new IRequestTarget() { public void detach(final RequestCycle requestCycle) {t.detach(requestCycle);} public void respond(final RequestCycle requestCycle) { t.respond(requestCycle); final WebResponse response = (WebResponse) requestCycle.getResponse(); response.setDateHeader("Expires", System.currentTimeMillis() + CACHE_DURATION * 1000L); response.setHeader("Cache-Control", "max-age=" + CACHE_DURATION); } }; } else { return null; } } }); } regards igor.vaynberg wrote: > > sfussenegger now has access to wicketstuff... > > i dont know which parts should go into wicket itself, i can tell you > that the part where you merge the files by listing them out upfront is > probably not going to make it in because it breaks encapsulation... > > -igor > > On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> I just finished the 4th and last entry of my series "Wicket Interface >> Speed-Up" on my blog. To give a short summary: I investigated one of my >> apps >> with YSlow and started optimizing it's interface rendering speed [1]. >> Especially Wicket's way of handling resources, i.e. JS and CSS files, >> causes >> interfaces to load rather slowly. In my articles, I explain how to modify >> the cache interval [2], how to mount resources with a version (e.g. >> /css/all-1234.css) in order to use aggressive client-side caching (e.g. >> resources expire after a year) [3]. Finally, I show how to merge >> resources >> at application startup (using a class classed MergedResourceStream) to >> reduce the number of resources a client has to download [4], including >> code). I was able to increase interface loading times considerably, so >> it's >> surely worth a look. >> >> I feel that it would also be worth to discuss, whether this work could be >> part of upcoming Wicket versions. For the time being I'd like to make the >> code attached to [4] a wicketstuff project - sfussenegger needs commit >> access ;) - and wait for your feedback. >> >> The links: >> [1] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >> Wicket Interface Speed-Up >> [2] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers >> [3] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >> Wicket Interface Speed-Up: Caching Resources Forever >> [4] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html >> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> ---
Re: Discussion on "Wicket Interface Speed-Up"
honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: > > @stefan: did you take into account > > > getApplication > ().getResourceSettings > ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? > > Cheers > Peter > > > Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: > >> sfussenegger now has access to wicketstuff... >> >> i dont know which parts should go into wicket itself, i can tell you >> that the part where you merge the files by listing them out upfront is >> probably not going to make it in because it breaks encapsulation... >> >> -igor >> >> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger >> <[EMAIL PROTECTED]> wrote: >>> >>> I just finished the 4th and last entry of my series "Wicket Interface >>> Speed-Up" on my blog. To give a short summary: I investigated one >>> of my apps >>> with YSlow and started optimizing it's interface rendering speed [1]. >>> Especially Wicket's way of handling resources, i.e. JS and CSS >>> files, causes >>> interfaces to load rather slowly. In my articles, I explain how to >>> modify >>> the cache interval [2], how to mount resources with a version (e.g. >>> /css/all-1234.css) in order to use aggressive client-side caching >>> (e.g. >>> resources expire after a year) [3]. Finally, I show how to merge >>> resources >>> at application startup (using a class classed MergedResourceStream) >>> to >>> reduce the number of resources a client has to download [4], >>> including >>> code). I was able to increase interface loading times considerably, >>> so it's >>> surely worth a look. >>> >>> I feel that it would also be worth to discuss, whether this work >>> could be >>> part of upcoming Wicket versions. For the time being I'd like to >>> make the >>> code attached to [4] a wicketstuff project - sfussenegger needs >>> commit >>> access ;) - and wait for your feedback. >>> >>> The links: >>> [1] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >>> Wicket Interface Speed-Up >>> [2] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control >>> Headers >>> [3] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >>> Wicket Interface Speed-Up: Caching Resources Forever >>> [4] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html >>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >>> >>> - >>> --- >>> Stefan Fußenegger >>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >>> -- >>> View this message in context: >>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.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] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.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]
Discussion on "Wicket Interface Speed-Up"
I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Escaping of strings containing & in attributes
no comments here? Stefan Fußenegger wrote: > > While validating some of my pages, I found out that some pages do not > validate due to & in attributes, e.g. > > > > W3 validator complains with: "character "&" is the first character of a > delimiter but occurred as data." > > I'm doing the following in code: > > class Image { String path; String alt; } > > // for StaticImage see > http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html > final StaticImage img = new StaticImage("image", new PropertyModel(img, > "path"))); > img.add(new AttributeModifier("alt", true, new PropertyModel(img, > "alt"))); > > if alt contains "foo & bar", the page won't validate. I think using > PropertyModel together with AttributeModifier is quite common. however, > the beans won't contain escaped markup ... hopefully ;) > > Should this be considered a bug? For the time beeing I use: > > new AttributeModifier("alt", true, new Model(album.getName())) { > protected String newValue(final String currentValue, final String > replacementValue) { > return Strings.escapeMarkup(replacementValue).toString(); > } > } > > > > btw: While looking for answers, I also found this (quite old) thread: > > http://www.nabble.com/Escaping-quotes-in-attributes-td11487305.html#a11487344 > > Al Maw mentions a comment in code: "attributes without values are > possible, e.g. 'disabled'" inside ComponentTag.writeOutput(...). As > mentioned and suggested in this thread, this is not true for XHTML and > should probably be fixed. However, the comment (and corresponding code) is > still there (at least in wicket 1.3.4). > > best regards and nice weekend! > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Escaping-of-strings-containing---in-attributes-tp18779532p18832765.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]
Escaping of strings containing & in attributes
While validating some of my pages, I found out that some pages do not validate due to & in attributes, e.g. W3 validator complains with: "character "&" is the first character of a delimiter but occurred as data." I'm doing the following in code: class Image { String path; String alt; } // for StaticImage see http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html final StaticImage img = new StaticImage("image", new PropertyModel(img, "path"))); img.add(new AttributeModifier("alt", true, new PropertyModel(img, "alt"))); if alt contains "foo & bar", the page won't validate. I think using PropertyModel together with AttributeModifier is quite common. however, the beans won't contain escaped markup ... hopefully ;) Should this be considered a bug? For the time beeing I use: new AttributeModifier("alt", true, new Model(album.getName())) { protected String newValue(final String currentValue, final String replacementValue) { return Strings.escapeMarkup(replacementValue).toString(); } } btw: While looking for answers, I also found this (quite old) thread: http://www.nabble.com/Escaping-quotes-in-attributes-td11487305.html#a11487344 Al Maw mentions a comment in code: "attributes without values are possible, e.g. 'disabled'" inside ComponentTag.writeOutput(...). As mentioned and suggested in this thread, this is not true for XHTML and should probably be fixed. However, the comment (and corresponding code) is still there (at least in wicket 1.3.4). best regards and nice weekend! - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Escaping-of-strings-containing---in-attributes-tp18779532p18779532.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localizer cache with 150.000+ entries causing OutOfMemory
Hi, According to https://issues.apache.org/jira/browse/WICKET-1667 this issue will be fixed in Wicket 1.3.4 and 1.4-M3 respectively. I already put the patch into production and it works. Thanks to Igor! Regards, Stefan Heart wrote: > > I've met the same problem several days away and resovled it by override a > method of Localizer > > see: > http://www.nabble.com/Why-Localizer-Retained-so-many-heapsize--to17142582.html#a17182935 > > that may help you a little. > > > 2008/6/9 Stefan Fußenegger <[EMAIL PROTECTED]>: > >> >> I am just analysing a heap dump (god bless the >> -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due >> to >> an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using >> jhat, the "175456 instances of class >> org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately >> got >> my attention. While looking through the 107 instance of >> ConcurrentHashMap, >> I >> found one *really* big one: Localizer.cache has a hash table length of >> 262144, each of its 32 segments with about 5300 entries, where a hash key >> is >> a string, sometimes longer than 500 charactes, similar to (see >> Localizer.getCacheKey(String,Component)): >> >> >> fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null >> >> Those numbers pretty much convinced me: The localizer cache has blown >> away >> my application. >> >> Looking at this hash keys, I suspect the following problem: those strings >> are constructed from the "position" of a localized String on a page, >> which >> is quite a bad thing if you use nested list views or repeating views to >> construct your page. For instance, I have a panel with a long (pageable) >> list of entries, might be > 5000 entries which might appear on various >> positions in a repeating view I use as a container for most of my pages. >> Let's say there are 5 possible positions, this would cause 2500 thousand >> cached entries, each with a key of 300+ characters plus some more >> characters >> for the cached message - feel free to do the maths. From a quick estimate >> I'd say: No wonder, this has blown away my app. >> >> As a quick fix, I'd suggest to regularly clear the localizer cache, use a >> more sophisticated cache (that expires old entries once in a while!!) or >> to >> disable the cache completely. However, don't try to overwrite >> Localizer.newCache() and clear the cache regularly: clearCache() will >> replace your cache with a ConcurrentHashMap (not using >> Localizer.newCache()). However, quite unlikely, that this will happen as >> newCache() is private anyway ;) I am going to add some code to clear the >> cache regularly. >> >> Best regards, Stefan >> >> PS: I'll also create a JIRA issue, but I am really short on time right >> now. >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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] >> >> > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p18000380.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localizer cache with 150.000+ entries causing OutOfMemory
Hi Daniel, I didn't put the patch into production yet, but I am quite confident, that it will help. As you can see in the example I attached to the JIRA issue (just attached a new version), the unpatched Localizer had 200 entries in his cache, the patched Localizer only four - which is a Good Thing (tm), as there are only 4 different cached values! Regards, Stefan Daniel Frisk wrote: > > So the patch did help? > > I too have observed this problem but it was at the moment less of a > problem than other heap eaters, now this is next in line. We have > added a script which automatically restarts the server when repeated > OOME occurs and are down to a couple of times per week without the > patch. But still, who wouldn't want to see months of uptime... > > // Daniel > jalbum.net > > > On 2008-06-10, at 11:29, Stefan Fußenegger wrote: > >> >> Hi Igor, >> >> Thanks for your quick reply and the patch, sorry for not searching the >> mailinglist only but not JIRA. >> >> Your patch was for 1.4, I applied it to 1.3.3, created a quickstart >> including JUnit test and attached it to the JIRA issue. Hope this >> fix gets >> into the next maintenance release. I am to lazy to create a properly >> patched >> jar and a MVN repo for my team right now ;) >> >> Regards, Stefan >> >> >> >> igor.vaynberg wrote: >>> >>> try applying this patch and see if it helps >>> >>> https://issues.apache.org/jira/browse/WICKET-1667 >>> >>> -igor >>> >>> On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> I am just analysing a heap dump (god bless the >>>> -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application >>>> cache due >>>> to >>>> an OutOfMemoryError ("GC overhead limit exceeded" to be precise). >>>> Using >>>> jhat, the "175456 instances of class >>>> org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" >>>> immediately >>>> got >>>> my attention. While looking through the 107 instance of >>>> ConcurrentHashMap, I >>>> found one *really* big one: Localizer.cache has a hash table >>>> length of >>>> 262144, each of its 32 segments with about 5300 entries, where a >>>> hash key >>>> is >>>> a string, sometimes longer than 500 charactes, similar to (see >>>> Localizer.getCacheKey(String,Component)): >>>> >>>> fooTitle.bar- >>>> org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink- >>>> org.apache.wicket.markup.html.panel.Fragment:track- >>>> org.apache.wicket.markup.html.list.ListItem:14- >>>> my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos- >>>> org.apache.wicket.markup.html.list.ListItem:0- >>>> my.company.BarListPanel$1:bars-my.company.FooListPanel:panel- >>>> my.company.boxes.BodyBox:2- >>>> org.apache.wicket.markup.repeater.RepeatingView:body- >>>> my.company.layout.Border:border-my.company.pages.music.FoobarPage: >>>> 43-de-null >>>> >>>> Those numbers pretty much convinced me: The localizer cache has >>>> blown >>>> away >>>> my application. >>>> >>>> Looking at this hash keys, I suspect the following problem: those >>>> strings >>>> are constructed from the "position" of a localized String on a page, >>>> which >>>> is quite a bad thing if you use nested list views or repeating >>>> views to >>>> construct your page. For instance, I have a panel with a long >>>> (pageable) >>>> list of entries, might be > 5000 entries which might appear on >>>> various >>>> positions in a repeating view I use as a container for most of my >>>> pages. >>>> Let's say there are 5 possible positions, this would cause 2500 >>>> thousand >>>> cached entries, each with a key of 300+ characters plus some more >>>> characters >>>> for the cached message - feel free to do the maths. From a quick >>>> estimate >>>> I'd say: No wonder, this has blown away my app. >>>> >>>> As a quick fix, I'd suggest to regularly clear the localizer >>>> cache, use a >>>> more sophisticated cache (that expires old entries once
Re: Localizer cache with 150.000+ entries causing OutOfMemory
Hi Igor, Thanks for your quick reply and the patch, sorry for not searching the mailinglist only but not JIRA. Your patch was for 1.4, I applied it to 1.3.3, created a quickstart including JUnit test and attached it to the JIRA issue. Hope this fix gets into the next maintenance release. I am to lazy to create a properly patched jar and a MVN repo for my team right now ;) Regards, Stefan igor.vaynberg wrote: > > try applying this patch and see if it helps > > https://issues.apache.org/jira/browse/WICKET-1667 > > -igor > > On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> I am just analysing a heap dump (god bless the >> -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due >> to >> an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using >> jhat, the "175456 instances of class >> org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately >> got >> my attention. While looking through the 107 instance of >> ConcurrentHashMap, I >> found one *really* big one: Localizer.cache has a hash table length of >> 262144, each of its 32 segments with about 5300 entries, where a hash key >> is >> a string, sometimes longer than 500 charactes, similar to (see >> Localizer.getCacheKey(String,Component)): >> >> fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null >> >> Those numbers pretty much convinced me: The localizer cache has blown >> away >> my application. >> >> Looking at this hash keys, I suspect the following problem: those strings >> are constructed from the "position" of a localized String on a page, >> which >> is quite a bad thing if you use nested list views or repeating views to >> construct your page. For instance, I have a panel with a long (pageable) >> list of entries, might be > 5000 entries which might appear on various >> positions in a repeating view I use as a container for most of my pages. >> Let's say there are 5 possible positions, this would cause 2500 thousand >> cached entries, each with a key of 300+ characters plus some more >> characters >> for the cached message - feel free to do the maths. From a quick estimate >> I'd say: No wonder, this has blown away my app. >> >> As a quick fix, I'd suggest to regularly clear the localizer cache, use a >> more sophisticated cache (that expires old entries once in a while!!) or >> to >> disable the cache completely. However, don't try to overwrite >> Localizer.newCache() and clear the cache regularly: clearCache() will >> replace your cache with a ConcurrentHashMap (not using >> Localizer.newCache()). However, quite unlikely, that this will happen as >> newCache() is private anyway ;) I am going to add some code to clear the >> cache regularly. >> >> Best regards, Stefan >> >> PS: I'll also create a JIRA issue, but I am really short on time right >> now. >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17751273.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]
Localizer cache with 150.000+ entries causing OutOfMemory
I am just analysing a heap dump (god bless the -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application cache due to an OutOfMemoryError ("GC overhead limit exceeded" to be precise). Using jhat, the "175456 instances of class org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry" immediately got my attention. While looking through the 107 instance of ConcurrentHashMap, I found one *really* big one: Localizer.cache has a hash table length of 262144, each of its 32 segments with about 5300 entries, where a hash key is a string, sometimes longer than 500 charactes, similar to (see Localizer.getCacheKey(String,Component)): fooTitle.bar-org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-org.apache.wicket.markup.html.panel.Fragment:track-org.apache.wicket.markup.html.list.ListItem:14-my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-org.apache.wicket.markup.html.list.ListItem:0-my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-my.company.boxes.BodyBox:2-org.apache.wicket.markup.repeater.RepeatingView:body-my.company.layout.Border:border-my.company.pages.music.FoobarPage:43-de-null Those numbers pretty much convinced me: The localizer cache has blown away my application. Looking at this hash keys, I suspect the following problem: those strings are constructed from the "position" of a localized String on a page, which is quite a bad thing if you use nested list views or repeating views to construct your page. For instance, I have a panel with a long (pageable) list of entries, might be > 5000 entries which might appear on various positions in a repeating view I use as a container for most of my pages. Let's say there are 5 possible positions, this would cause 2500 thousand cached entries, each with a key of 300+ characters plus some more characters for the cached message - feel free to do the maths. From a quick estimate I'd say: No wonder, this has blown away my app. As a quick fix, I'd suggest to regularly clear the localizer cache, use a more sophisticated cache (that expires old entries once in a while!!) or to disable the cache completely. However, don't try to overwrite Localizer.newCache() and clear the cache regularly: clearCache() will replace your cache with a ConcurrentHashMap (not using Localizer.newCache()). However, quite unlikely, that this will happen as newCache() is private anyway ;) I am going to add some code to clear the cache regularly. Best regards, Stefan PS: I'll also create a JIRA issue, but I am really short on time right now. - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use Spring with Wicket
Martijn Dashorst compiled a nice list of books (3 for beginners, another 3 on advanced topics) that will certainly help you to get started: http://martijndashorst.com/blog/2008/05/25/wicket-starter-kit/ Regards - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17619622.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. I didn't read all of the posts here, but I would suggest to go for Component or even @SuppressWarnings("unchecked"). This way, you don't have to use generified components but are still able to do so. Currently, I am always passing models as parameter to the constructor of my custom components. Those parameters are always named according to the expected type they contain (e.g. fooModel if i expect an object of type Foo in there). Therefore, generics could jump in quite easily and I am looking forward to use them! - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17618096.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leak in DiskPageStore
https://issues.apache.org/jira/browse/WICKET-1679 Matej Knopp-2 wrote: > > Hi, > > about not removing the entries, can you please create jira issue? I > will try to look into it ASAP. > > -Matej > > On Mon, Jun 2, 2008 at 11:38 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> Recently, I had 2 memory related crashes of my Wicket app. Thanks to the >> priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to >> look >> at (one crash was due to a GC overhead exception, so no dump there). One >> thing that immediately attracted my attention was that there were 116.917 >> instances of >> org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As >> objects of this class "represent a session" (javadoc), it seems that I >> had >> 116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap. >> >> In my app, i spotted two reasons for this; >> 1. search engine bots (e.g. googlebot) receive a new session for each >> page >> they access, as we cut of the ;jsessionid= from the URL in our app in >> order >> not to have those ugly IDs on the search engine result pages. As a >> result, >> when google tried to index 100.000+ pages 100.000+ sessions had been >> created. I am certainly going to work on this issue, however, it helped >> me >> to spot reason number 2: >> >> 2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I >> guess, >> this should be added to the DiskPageStore.unbind(String sessionId) >> method: >> >>public void unbind(String sessionId) >>{ >>// FIX: replace get() with remove() >>SessionEntry entry = >> (SessionEntry)sessionIdToEntryMap.get(sessionId); >>if (entry != null) >>{ >>if (isSynchronous()) >>{ >>entry.unbind(); >>} >>else >>{ >>List pages = >> getPagesToSaveList(sessionId); >>synchronized (pages) >>{ >> flushPagesToSaveList(sessionId, >> pages); >>entry.unbind(); >>} >>pagesToSaveAll.remove(sessionId); >>} >>} >>} >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597859.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]
Memory leak in DiskPageStore
Recently, I had 2 memory related crashes of my Wicket app. Thanks to the priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to look at (one crash was due to a GC overhead exception, so no dump there). One thing that immediately attracted my attention was that there were 116.917 instances of org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As objects of this class "represent a session" (javadoc), it seems that I had 116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap. In my app, i spotted two reasons for this; 1. search engine bots (e.g. googlebot) receive a new session for each page they access, as we cut of the ;jsessionid= from the URL in our app in order not to have those ugly IDs on the search engine result pages. As a result, when google tried to index 100.000+ pages 100.000+ sessions had been created. I am certainly going to work on this issue, however, it helped me to spot reason number 2: 2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I guess, this should be added to the DiskPageStore.unbind(String sessionId) method: public void unbind(String sessionId) { // FIX: replace get() with remove() SessionEntry entry = (SessionEntry)sessionIdToEntryMap.get(sessionId); if (entry != null) { if (isSynchronous()) { entry.unbind(); } else { List pages = getPagesToSaveList(sessionId); synchronized (pages) { flushPagesToSaveList(sessionId, pages); entry.unbind(); } pagesToSaveAll.remove(sessionId); } } } - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to avoid Lazy loading exception
Do you have OpenSessionInViewFilter in your web.xml? If no, you will get this exception whenever you try to do lazy loading outside your DAOs. add to web.xml: OpenSessionFilter org.springframework.orm.hibernate3.support.OpenSessionInViewFilter sessionFactoryBeanName hibernateSessionFactory OpenSessionFilter /* I always use a self-written class called PersistentObjectModel (a LoadableDetachableModel) and let all my Persisent classes implement an interface called IPersistentObject with a single method: Serializable getId() public class PersistentObjectModel extends LoadableDetachableModel { private static final long serialVersionUID = 1L; private final Class _clazz; private final int _id; @SpringBean(name = "myDao") private IMyDao _myDao; @SuppressWarnings("unchecked") public PersistentObjectModel(final T object) { super(object); if (object instanceof HibernateProxy) { _clazz = (Class) ((HibernateProxy) object).getHibernateLazyInitializer() .getImplementation().getClass(); } else { _clazz = (Class) object.getClass(); } _id = object.getId(); // inject the bean InjectorHolder.getInjector().inject(this); } public PersistentObjectModel(final Class clazz, final int id) { _clazz = clazz; _id = id; // inject the bean InjectorHolder.getInjector().inject(this); } @Override protected T load() { return _myDao.getById(_clazz, _id); } @SuppressWarnings("unchecked") @Override public T getObject() { return (T) super.getObject(); } } This makes working with hibernate objects really easy: setModel(new PersistentObjectModel(Foo.class, 1)); // option 1: class and id setModel(new PersistentObjectModel(foo)); // option 2: persistent object - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/How-to-avoid-Lazy-loading-exception-tp17040941p17045620.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]
Wicket fail-over with Terracotta - sticky or non-sticky sessions?
Hi all, I am currently evaluating a Wicket fail-over solution (two equal nodes with a floating IP, probably using Linux Heartbeat) with Terracotta. Of course, it would be desirable to switch between nodes without any impact on a user's session. In order to provide this, the cluster must be able to handle non-sticky sessions. Session clustering works like a breeze with Wicket and Terracotta I already spotted a problem with buffered redirects, that could be avoided with a different rendering strategy (IRequestCycleSettings.REDIRECT_TO_RENDER). However, this problem would only occur if a node goes down just when the client is redirecting - not very likely and probably acceptable as switching over might take a few seconds anyway. Now my question: What other problems could appear when I only use session clustering for fail-over purposes? Can I stay with the default rendering strategy (IRequestCycleSettings.REDIRECT_TO_BUFFER) without clustering the buffer if I accept missing feedback messages in the above scenario? Any further comments on my setup will be appreciated as well! (If answers are woth it, I'll create a wiki page out of this thread) Best Regards, Stefan - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Wicket-fail-over-with-Terracotta---sticky-or-non-sticky-sessions--tp16467830p16467830.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing prototype scoped panel beans using @SpringBean annotation
What do you mean by "directly"? Do you want to inject the panels rather than the factories? You could probably try to write your own annotation and use a custom org.apache.wicket.injection.IFieldValueFactory Ned Collyer wrote: > > > Stefan Fußenegger wrote: >> >> Hi Tom, >> >> I'd suggest not to use Spring to manage panels. You should rather create >> a new panel for every page and request. You should use Spring to manage >> your services and inject those into your panels. >> >> Best regards, Stefan >> > > Hi Stephan :) (I work with Tom) > > We have a work around for this specific problem, and it still involves > spring, but not using panels directly. > > Basically the situation is as follows. > > We have a main wicket project which is published as a jar. > > There are also other modules also published as "plugin" jars. > > We launch these with an embedded jetty instance. > > The problem is the Main project contains the page instances, and the other > jars contain the panels. > > The Main project has no idea about which panels are available, as these > will be determined at run time by whatever has been configured (thru > spring). The main jar has no knowledge of which panel classes exist - so > we cannot really instantiate new ones using plain old java. > > There are a few ways to approach this, ie, having some class loader which > resolves given string "class references", and those strings are wired in > through spring. This works - but feels a bit hacky. > > Our workaround is .. somewhat similar - we basically have a panel factory > in the plugin that instantiate a panel and return it. We can then wire > these panel factories thru spring to a given page. > > This turns out to be quite elegant - however it would be nice if we had > the ability to wire "plugin" panels to the main jar directly without this > factory. > > Rgds > > Ned > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Accessing-prototype-scoped-panel-beans-using-%40SpringBean-annotation-tp15627974p15632905.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to create the component dynamic?
Hi Mead, I'd say that wicket is a real cool choice to accomplish this (I know what I'm talking about as I hacked such a tool in PHP years ago in my programming infancy ;) ) There is no general answer though. But for different question types you could do if (type == DROP_DOWN_QUESTION) add(new DropDownQuestionPanel("panel", question); else if (type == RADIO_QUESTION) add(new RadioQuestionPanel("panel", question); // you got the idea you could also create the panels dynamically by giving a type such as "com.foo.questiontype.DropDown" using reflection. This way you could create a quite flexible solution, where you could drop in just another jar to add new question types. If it comes to different numbers of possibilities, RepeatingView might be a good choice. Best regards and good luck Mead-2 wrote: > > Well, I wanne build a Survey-System! > Now there're some Questions in the Survey-System, and will default some > answer-item for user to choice! > following is the example of Question > 1,It's the weather good today?(A.B.C. would be radio) > A.yes, Sunny > B.no, Rainy > C.so so > I think all the component shall be created at run time! but some question > has 5 items some has 3 items, > some is a TextField which filled by user, some is CheckBox or Radio. > How to do with this? > > Mead > > > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/how-to-create-the-component-dynamic--tp15630091p15631519.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing prototype scoped panel beans using @SpringBean annotation
vailable(HttpParser.java:210) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) > > Complete stack: > > org.apache.wicket.WicketRuntimeException: Error attaching this container > for rendering: [Page class = com.example.TestPage, id = 0, version = 0] > at > org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1525) > at org.apache.wicket.Component.onBeforeRender(Component.java:3657) > at org.apache.wicket.Page.onBeforeRender(Page.java:1402) > at org.apache.wicket.Component.internalBeforeRender(Component.java:995) > at org.apache.wicket.Component.beforeRender(Component.java:1027) > at org.apache.wicket.Component.prepareForRender(Component.java:2139) > at org.apache.wicket.Page.renderPage(Page.java:870) > at > org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:231) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) > > > Can anyone throw some light on what I'm doing wrong. I'm not tied to the > idea of the Panels being prototype beans however without it, immediately > on server startup, I get a "WicketRuntimeException: There is no > application attached to current thread main". Making them prototype seems > to be the only way for me to get my server to startup cleanly. > > Thanks, > Tom. > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Accessing-prototype-scoped-panel-beans-using-%40SpringBean-annotation-tp15627974p15631515.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]
usage of AbortWithHttpStatusException
Hi, How is AbortWithHttpStatusException meant to be used? I expected that this exception would result in a (e.g.) 404 error page to be shown. However, all I get is an empty page. Any ideas on how I can get a nice, custom error page to show up? Cheers, Stefan btw: i'm using jetty if this is important. - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/usage-of-AbortWithHttpStatusException-tp15631513p15631513.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RestartResponseAtInterceptPageException with Ajax
I was just waiting for green lights ;) https://issues.apache.org/jira/browse/WICKET-1363 igor.vaynberg wrote: > > feel free to add a jira request for this > > -igor > > > On Thu, Feb 21, 2008 at 4:44 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> Maurice, >> >> Thanks for your suggestions. However, these suggestions are yet 2 other >> workarounds for this problem. >> >> imho, using RestartResponseAtInterceptPageException and >> continueToOriginalDestination() should work out of the box, regardless >> of >> the type of request (Ajax and non-Ajax). Therefore I suggest adding >> support >> to the framework - and your suggestions did not convince me not to do >> so, >> sorry ;) >> >> However, the strategy to choose a page for >> continueToOriginalDestination() >> is open for discussion. The simplest approach would be to go back to the >> source of the Ajax request, while allowing to complete the request and >> render the entire page afterwards would be best. >> >> -- Stefan >> >> >> >> >> >> Mr Mean wrote: >> > >> > Hmm, i'm not sure this will work at all with the restartresponse but i >> > have 2 alternatives that do not require changes to wicket >> > >> > -append some javascript to the ajaxrequesttarget that will trigger the >> > browser to request your login page (you can get the wicket url for the >> > loginpage using urlFor) >> > if your login page accepts pageparams you can use those to decide >> > what the response for a successful login should be. >> > >> > -open you login page in a ModalWindow on the same page and close it >> > after a successful login (you might need to refresh the origin page >> > after this) >> > >> > Maurice >> > >> > On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger >> > <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi, >> >> >> >> I'm currently trying to use RestartResponseAtInterceptPageException >> with >> >> Ajax. More precisely, I show a component that refreshes itself after >> >> executing an authorized action. It the user is not authorized to >> execute >> >> this action, I'd like to redirect him to the Login-Page. After >> proper >> >> login, >> >> the user should be redirected to the original page. However, using >> >> continueToOriginalDestination() does not work (out of the box), as >> the >> >> User >> >> is redirected to the URL of the Ajax request. >> >> >> >> >> >> Workaround/Possible changes to simplify workaround: >> >> >> >> A custom workaround would be to do a custom PageMap implementation. >> >> However, >> >> as the method setUpRedirect(RequestCycle) is private, deriving from >> the >> >> default PageMap will require some ugly copy-paste in order to do so. >> >> This >> >> could be avoided by a) making setUpRedirect(RequestCycle) protected >> >> and/or >> >> b) introduce a protected method that constructs the >> >> interceptContinuationURL >> >> inside setUpRedirect(RequestCycle). >> >> >> >> >> >> Changing default behaviour: >> >> >> >> The workaround version is not trivial, as in requires quite a bit of >> >> knowledge of Wicket's inner workings ("What the hell is a >> PageMap?"). >> >> Therefore, it might be a good idea to change the default behaviour >> >> there, as >> >> no user wants to see Ajax responses at all (well, at least no normal >> >> user - >> >> I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour >> be >> >> somewhat more intelligent by default (without hacking a custom >> PageMap)? >> >> That is to redirect to the page the Ajax request belonged to? Or >> even >> >> better: redirect to the Ajax call and render the complete page >> (well, >> >> don't >> >> know how tricky that would be). >> >> >> >> Or do I miss something completely? Any other possible workarounds or >> >> suggestions? >> >> >> >> Cheers, Stefan >> >> >> >> - >> >> --- >&g
Re: RestartResponseAtInterceptPageException with Ajax
Maurice, Thanks for your suggestions. However, these suggestions are yet 2 other workarounds for this problem. imho, using RestartResponseAtInterceptPageException and continueToOriginalDestination() should work out of the box, regardless of the type of request (Ajax and non-Ajax). Therefore I suggest adding support to the framework - and your suggestions did not convince me not to do so, sorry ;) However, the strategy to choose a page for continueToOriginalDestination() is open for discussion. The simplest approach would be to go back to the source of the Ajax request, while allowing to complete the request and render the entire page afterwards would be best. -- Stefan Mr Mean wrote: > > Hmm, i'm not sure this will work at all with the restartresponse but i > have 2 alternatives that do not require changes to wicket > > -append some javascript to the ajaxrequesttarget that will trigger the > browser to request your login page (you can get the wicket url for the > loginpage using urlFor) > if your login page accepts pageparams you can use those to decide > what the response for a successful login should be. > > -open you login page in a ModalWindow on the same page and close it > after a successful login (you might need to refresh the origin page > after this) > > Maurice > > On Thu, Feb 21, 2008 at 10:30 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> I'm currently trying to use RestartResponseAtInterceptPageException with >> Ajax. More precisely, I show a component that refreshes itself after >> executing an authorized action. It the user is not authorized to execute >> this action, I'd like to redirect him to the Login-Page. After proper >> login, >> the user should be redirected to the original page. However, using >> continueToOriginalDestination() does not work (out of the box), as the >> User >> is redirected to the URL of the Ajax request. >> >> >> Workaround/Possible changes to simplify workaround: >> >> A custom workaround would be to do a custom PageMap implementation. >> However, >> as the method setUpRedirect(RequestCycle) is private, deriving from the >> default PageMap will require some ugly copy-paste in order to do so. >> This >> could be avoided by a) making setUpRedirect(RequestCycle) protected >> and/or >> b) introduce a protected method that constructs the >> interceptContinuationURL >> inside setUpRedirect(RequestCycle). >> >> >> Changing default behaviour: >> >> The workaround version is not trivial, as in requires quite a bit of >> knowledge of Wicket's inner workings ("What the hell is a PageMap?"). >> Therefore, it might be a good idea to change the default behaviour >> there, as >> no user wants to see Ajax responses at all (well, at least no normal >> user - >> I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be >> somewhat more intelligent by default (without hacking a custom PageMap)? >> That is to redirect to the page the Ajax request belonged to? Or even >> better: redirect to the Ajax call and render the complete page (well, >> don't >> know how tricky that would be). >> >> Or do I miss something completely? Any other possible workarounds or >> suggestions? >> >> Cheers, Stefan >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15610291.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]
RestartResponseAtInterceptPageException with Ajax
Hi, I'm currently trying to use RestartResponseAtInterceptPageException with Ajax. More precisely, I show a component that refreshes itself after executing an authorized action. It the user is not authorized to execute this action, I'd like to redirect him to the Login-Page. After proper login, the user should be redirected to the original page. However, using continueToOriginalDestination() does not work (out of the box), as the User is redirected to the URL of the Ajax request. Workaround/Possible changes to simplify workaround: A custom workaround would be to do a custom PageMap implementation. However, as the method setUpRedirect(RequestCycle) is private, deriving from the default PageMap will require some ugly copy-paste in order to do so. This could be avoided by a) making setUpRedirect(RequestCycle) protected and/or b) introduce a protected method that constructs the interceptContinuationURL inside setUpRedirect(RequestCycle). Changing default behaviour: The workaround version is not trivial, as in requires quite a bit of knowledge of Wicket's inner workings ("What the hell is a PageMap?"). Therefore, it might be a good idea to change the default behaviour there, as no user wants to see Ajax responses at all (well, at least no normal user - I really enjoy their unrivalled beauty ;) ). Shouldn't the behaviour be somewhat more intelligent by default (without hacking a custom PageMap)? That is to redirect to the page the Ajax request belonged to? Or even better: redirect to the Ajax call and render the complete page (well, don't know how tricky that would be). Or do I miss something completely? Any other possible workarounds or suggestions? Cheers, Stefan - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/RestartResponseAtInterceptPageException-with-Ajax-tp15607225p15607225.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Server-independent) Comet support in Wicket?
wicketstuff-push might be what you are looking for: wicket cometd support with jetty. but i don't think that anybody has used it with 10k simultaneous users yet. see: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ Jörn Zaefferer-2 wrote: > > Hi, > > I've started evaluating Wicket today for an application written from > scratch. First impressions are very well, there is just one > requirement on which I couldn't find enough useful information yet: > Comet support in Wicket or Comet with Wicket. > > Before looking at Wicket I tried to use lift which has Comet support > built in (based on Scala Actors). This post > (http://blogs.webtide.com/gregw/2006/07/25/1153845234453.html) > suggests that its not possible to implement scaleable Comet support > within a web framework, instead it must be supported by the > application server, eg. Jetty 6. > > Post about Comet and Wicket, eg. this one > (http://www.mail-archive.com/[EMAIL PROTECTED]/msg17308.html) > don't give me any actual information about the current state of afairs > (its from 2006, the linked sf.net issue is now private). This issue > (http://wicketstuff.org/jira/browse/DOJO-23) about integration with > cometd isn't too helpful either, I can't find any documentation on > that. > > To provide some information on the actual requirements I have: The > architecture must support several both dependent and independent > components on a single page which get updated based on server-events, > be it on schedules or events triggered by other users. While the exact > number of simultaneous users isn't clear yet, up to 10k must be > possible with the appropriate hardware. > > Thanks > Jörn Zaefferer > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/%28Server-independent%29-Comet-support-in-Wicket--tp15574656p15589149.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minor Announcement: wicket-googlecharts
Hi Daniel, Last week I did exactly the same as you did here and was also planing to release it as wicketstuff project ... i think this could be called bad timing ;) Maybe we could collaborate on this in the future (I'll have a closer look after Christmas and maybe merge my stuff with yours) Regards, Stefan Daniel Spiewak wrote: > > Just a minor sidebar, at Johan's suggestion I've released > wicket-googlecharts into the wicket-stuff project. I played with the > build > system a bit to make it work with maven and I think I did it right, but my > maven experience is limited. License is currently discretionary, though > if > I really had to pick one I'd probably go with either ASL2 or BSD. > > Warning: anything that isn't tested by the test page in the project is > completely theoretical and untested. This means things like scatter > plots, > color fills, etc are all up in the air. I'll probably get around to > stabilizing functionality eventually, but for now it can just float. > Hopefully someone will find this useful! > > Daniel > > (original article: > http://www.codecommit.com/blog/java/a-wicket-api-for-google-charts) > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Minor-Announcement%3A-wicket-googlecharts-tp14442165p14454946.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple thread
;> 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] >> >> > > > -- > Bruno Borges > blog.brunoborges.com.br > +55 1185657739 > > "The glory of great men should always be > measured by the means they have used to > acquire it." > - Francois de La Rochefoucauld > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13690139 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple thread
Of course, it really is optional. Wicket only checks whether a page has a tag or not to decide if markup merging is needed. (Therefore, my patch does not have any impact on that, as there is no markup merging triggered) Thanks for pointing this out! -- stefan Sebastiaan van Erk wrote: > > 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). > > 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. > > Regards, > Sebastiaan > > Stefan Fußenegger wrote: >> I think it would be a nice feature to define defaults and overrides this >> way. >> However, this wouldn't be backwards compatible anymore as the contents >> are >> currently ignored. (Ok, you are currently forced to extend them, so you >> probably wouldn't see the markup from such sections in *old* >> applications.) >> >> My vote on this: >> - I would love to have multiple sections. >> - I would appreciate default markup for extendible sections. >> >> Kind regards, >> >> -- stefan >> >> PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :) >> >> >> >> Chris Colman wrote: >>>> 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] >>> >>> >>> >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13666078 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: facebook support
I'd be interested in Facebook and Open Social support. However, I don't have any experience with either of them. It would be extremely cool to have a common interface for both of them - write once run everywhere. I would also help implementing it. I don't have much time to spend tough. For my project, facebook and open social support won't be required within the next 6 month. (But it would be cool to have.) -- Stefan Jonathan Locke wrote: > > I'd like to get facebook support into Wicket. If anyone out there has > interest and would like to cooperate(particularly anyone with Facebook > experience), please get in touch with me. Thanks. > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/facebook-support-tf4773546.html#a13662919 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple thread
I think it would be a nice feature to define defaults and overrides this way. However, this wouldn't be backwards compatible anymore as the contents are currently ignored. (Ok, you are currently forced to extend them, so you probably wouldn't see the markup from such sections in *old* applications.) My vote on this: - I would love to have multiple sections. - I would appreciate default markup for extendible sections. Kind regards, -- stefan PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :) Chris Colman wrote: > >> 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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13662915 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple thread
Hi eelco. Did you see what I changed in order to make this working? There is nearly no extra complexity. So I think complexity isn't an argument here. best regards -- stefan Eelco Hillenius wrote: > >> 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) > > The thing is though, even though it is 100% backwards compatible, it > is something we'll have to support. It adds complexity to the > implementation, and we'll have to answer questions about it on the > list. That would be fine if everyone would have been wildly > enthusiastic about it, but that is not the case - whether you think > that is justified or not. > > So, like I propose in the main thread, the best way to go is to > implement this as a separate project, using separate tags. We'll be > happy to support any internal API changes if that is needed to make > the implementation work. 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 ;-) > > Do people want to work on this? > > Regards, > > Eelco > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13643264 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
hi eelco, Assume the tag wouldn't be renamed. Then it would only be a new and optional (!) attribute for the child/extend tags. So isn't it unnecessary to explicitly turn on/off a feature that you could implicitly turn on as soon as this attribute is used? The naming - is abstract/implement better than child/extend - is another topic I really didn't want to argue about. This is just an idea. I know that supporting it as wicket core feature (docs, mailing list, code, ...) is a totally different question. regards, stefan 100th reply - is it a Good Thing (tm) ;) Eelco Hillenius wrote: > > On Nov 7, 2007 11:19 AM, Scott Swank <[EMAIL PROTECTED]> wrote: >> I can see how and tags could be >> a nice enhancement to the current and >> tags. Do you have a working, or mostly working, patch? > > What I think we should do with this is make it an option. It would be > turned off by default, requiring users to an extra one or two lines of > configuration to turn this on (we've done this before), and let it > prove itself. Sounds to me like everyone would be happy. > > WDYT? > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13643104 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Yes! see: https://issues.apache.org/jira/browse/WICKET-1134 -- stefan Scott Swank wrote: > > I can see how and tags could be > a nice enhancement to the current and > tags. Do you have a working, or mostly working, patch? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13634545 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
But the number of added panels needn't be the number of abstract section (though it could). -- stefan Jan Kriesten wrote: > > > hi stefan, > >> 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). > > regards, --- jan. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631624 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
>From the Java-side, it isn't visible, whether a component will be placed in whatever html part. So you add all components in the constructor, yes. However, it's as messy as adding 5 components is right now ... they will just be added at different places. 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. Is that what you meant? -- stefan Johan Compagner wrote: > > no not the merging of markup. > but inside the constructor of the child/sub page. > Where do you make all the root components of all the child parts? > you will add that to the page itself right? > > I just say that then it could be a bit messy when you have 5 child area's > > johan > > > > On 11/7/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> >> hi johan, >> >> >> Johan Compagner wrote: >> > >> > 1 thing that does bother me a bit (but maybe i have to do a deeper look >> > into >> > the patch) how do you separate >> > the components in the constructor of the sub page.. i guess you just >> add >> > all >> > the components over all the child fragments >> > in the page itself. That's not a nice separation... That can lead to >> big >> a >> > big mess.. Because what component belong to what child part. " >> > >> >> I don't get what you mean here. However, my implementation is closely >> related to Juergen's MergedMarkup.java (and admittedly partially copied) >> and >> does the same. >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631363 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
hi johan, Johan Compagner wrote: > > 1 thing that does bother me a bit (but maybe i have to do a deeper look > into > the patch) how do you separate > the components in the constructor of the sub page.. i guess you just add > all > the components over all the child fragments > in the page itself. That's not a nice separation... That can lead to big a > big mess.. Because what component belong to what child part. " > I don't get what you mean here. However, my implementation is closely related to Juergen's MergedMarkup.java (and admittedly partially copied) and does the same. - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Well, if naming is your only concern, the attribute's name can easily be replaced with something else than id ... e.g. name some text and remember that they can be optional as well: some text This way, its completely compatible with child/extend (which can be proofed with the existing junit test for markup inheritance) just a question: do i start to convince you? ;) best regards Bruno Borges wrote: > > Let me paste what I commented in WICKET-1134: > > *I think this improvement is just more of a way to "override" components > declared in markups of a super class. Because this is what really happens. > Let's check your example: > > In the BasePage, there are two fragments: > - subNavigation > - content > > What about if I want to have a fragment in SectionPage with id "content", > but not related with that content from BasePage? You see, the concept of > extend/child, is the same as in OOP's inheritance. What goes in child, is > from the subclass. Period. > > In Java, if you declare: > class BasePage ... { > protected Object someProperty; > } > > class SectionPage extends BasePage { > protected Object someProperty; > } > > What happens here is that SectionPage.someProperty does NOT > override/implement/whatever-you-wanna-call, BasePage.someProperty. What > you > want to do in HTML would be this in Java. > > I'm worry about people trying to subclass some WebMarkupContainer, and > having to be carefully with components ids, just to _not_ match something > that would generate strange output. > > If in SectionPage I add some component (like Label) with "content" id, > what > would happen? Throw a message: "You cannot use this id because there's an > abstract 'content' markup in BasePage.html". This would lead to code in > HTML > that has NO reference within it's Java class. > > This means that: what you don't see in Java, it *might* be possible to > exist > in the HTML. > > And what I like most of Wicket, is its ability to let me take control of > everything, just from one source: Java. But if I'm going to be obligated > of > taking care of what people declare in HTML files that I can't see in some > Java source code, then I will reconsider my framework's choice. > > Regards* > > Now, Stefan, let me reply your last comment in the issue: > *No, ids used with abstract/implement are completely different from > wicket:ids ... they are only used to construct (i.e. merge ... or link) > the > markup, so it is perfectly legal to use when there > is > a somewhere, as they won't be related. > Therefore, > no of the concerns you mention would apply, as ... > > The concept of abstract/implement is the same as in OOP's inheritance. > What > goes in child, is from the subclass! Exclamation mark! ;)* > > Ok, you propose a new attribute for extend/abstract, child/implement pair > tags. And you say that this id attribute will NOT have any relationship > with > wicket:id. Well, isn't this something... scary? The documentation will > have > to take care of this, because it will _not_ be intuitive. > > Regards, > > > On Nov 7, 2007 10:15 AM, Stefan Fußenegger <[EMAIL PROTECTED]> > wrote: > >> >> Hi Mats, let me try to explain what Chris and I see here that others >> don't >> - >> may it be there or not ;) >> >> You can of course do everything with panels that could be done with >> multiple >> abstract sections (may they be named wicket:child or wicket:abstract). >> However, if this is the only argument, you wouldn't need markup >> inheritance >> at all! The proposed change is just an extension of exactly this markup >> inheritance concept (that everybody loves) to make it even more powerful >> than it already is. >> >> I was quite new to wicket (which I still am) and came across a situation >> where I wanted to use two abstract sections: one for a sub-navigation >> that >> was common for several pages in a section and one for the actual content. >> For me, as a wicket newbie, it would have been most natural to use markup >> inheritance to solve this problem. Using abstract methods, while being a >> nice solution (workaround?), didn't come to my mind at once, nor did I >> find >> it somewhere in the docs. >> >> imho, there are two possible solution to this problem: >> 1. promote using abstract methods for this in the docs as the wicket-way >> of >> doing it >> 2. extend the current markup inheritance mechanism (which I tried to do >>
RE: Multiple tags on a single base page?
> 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] >> > >> > >> > >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: http://www.nabble.com/Multiple- >> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page-- >> tf4738673.html#a13623108 >> 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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626128 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Hi Mats, let me try to explain what Chris and I see here that others don't - may it be there or not ;) You can of course do everything with panels that could be done with multiple abstract sections (may they be named wicket:child or wicket:abstract). However, if this is the only argument, you wouldn't need markup inheritance at all! The proposed change is just an extension of exactly this markup inheritance concept (that everybody loves) to make it even more powerful than it already is. I was quite new to wicket (which I still am) and came across a situation where I wanted to use two abstract sections: one for a sub-navigation that was common for several pages in a section and one for the actual content. For me, as a wicket newbie, it would have been most natural to use markup inheritance to solve this problem. Using abstract methods, while being a nice solution (workaround?), didn't come to my mind at once, nor did I find it somewhere in the docs. imho, there are two possible solution to this problem: 1. promote using abstract methods for this in the docs as the wicket-way of doing it 2. extend the current markup inheritance mechanism (which I tried to do with my patch/prototype) -- stefan Mats Norén-2 wrote: > > On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote: >> Hmm...I'm interested in seeing the difference as well. I would love to >> get it but right now I don't. >> >> Chris Colman wrote: >> "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." >> >> Is the above statement really true considering that by adding abstract >> methods to your page you defer the creation of the markup in just the >> same way as the new proposed solution? >> >> BasePage.java >> >> public BasePage() { >> addAbstract1("abstractId1"); >> addAbstract2("abstractId2); >> } >> >> public abstract addAbstract1(String abstractId1); >> public abstract addAbstract2(String abstractId2); > > A little typo here..I meant: > > public BasePage() { > add(addAbstract1("abstractId1")); > add(addAbstract2("abstractId2)); > } > > public abstract Component addAbstract1(String abstractId1); > public abstract Component addAbstract2(String abstractId2); > > /Mats > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
Hey Chris, I would need some lobbying here! ;) -- stefan 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 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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623108 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Well, the tags are not new, as they do the perfectly same as extend and child. Basically, the patch only introduces an id attribute to those tags in order to make linking of markup more flexible. The new names were only introduced to keep functionality of the patch separated from the existing (and as the names child/extend are not very well chosen, as they aren't naturally related) I see that it was a bad idea to rename the tags for the prototype. Obviously, everybody fears new tags and therefore dismisses the whole idea only for that reason. Evan Chooly wrote: > > In our app we have a ListView into which we can dump panels for, in > our case, various different filtering options depending on the page. > The base page keeps a List and that's used as the model for the > ListView. If the subclass doesn't add anything, nothing shows up. > But the pages that need them can add them. These panels show up in > the base page's markup area (outside the area) with no > hackery needed. > > I think the proposed patch is an overly complicated solution to > "problem" that has many different simple solutions. I agree with the > earlier comments about the proliferation of tags in wicket. I'd > rather not see new tags added just for this. It fuglifies the markup > for no real gain. > > On Nov 6, 2007 11:30 AM, Stefan Fußenegger <[EMAIL PROTECTED]> > wrote: >> >> I posted a new message in Wicket - Dev: >> http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html >> >> It contains a patch that demonstrates the discussed enhancement. Please >> comment! >> >> -- stefan >> >> >> Stefan Fußenegger wrote: >> > >> > Hi folks, >> > >> > I just stumbled on a situation where it would be useful to have two or >> > more tags in a base page. Just consider a layout that >> > consists of the usual footer, header, navigation, and content parts. >> But >> > now, the content should be arranged in two columns, e.g. two different >> > s. >> > >> > To give a short example, the BasePage.html cloud look like this >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > And the Child.html markup would look like this: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Wouldn't that be a desirable feature? I tried to run the above example >> > expecting to get an exception. The second wicket:child/wicket:extend >> pair >> > was happily ignored though. >> > >> > Best regards, Stefan >> > >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287 >> >> 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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623106 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make PageableListView row click
add javascript to your tags pure html sample: Test Test Test Test (Source: http://radio.javaranch.com/pascarello/2004/12/30/1104419159000.html) Marco Aurélio Silva wrote: > > Hi all > > I'm using a PageableListView component and I want to make each row of the > list clickable. I don't want to add a column with a label like "details", > I > just want to click in any place of the row to go to details. Is there a > way > to do this? > > Thanks in advance > Marco > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Make-PageableListView-row-click-tf4759886.html#a13612378 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
I posted a new message in Wicket - Dev: http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html It contains a patch that demonstrates the discussed enhancement. Please comment! -- stefan Stefan Fußenegger wrote: > > Hi folks, > > I just stumbled on a situation where it would be useful to have two or > more tags in a base page. Just consider a layout that > consists of the usual footer, header, navigation, and content parts. But > now, the content should be arranged in two columns, e.g. two different > s. > > To give a short example, the BasePage.html cloud look like this > > > > > > > > > > > > > > > > > > > > > And the Child.html markup would look like this: > > > > > > > > > > > > > > > > > > > Wouldn't that be a desirable feature? I tried to run the above example > expecting to get an exception. The second wicket:child/wicket:extend pair > was happily ignored though. > > Best regards, Stefan > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
The proposed extension would just lead to more convenience, as it saves us from having to create child pages as page/panel pairs when their are 2 panels needed (assuming no inheritance at all) John Krasnay wrote: > > On Tue, Nov 06, 2007 at 10:23:26PM +1100, Chris Colman wrote: >> >> 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 > > Huh? Why wouldn't the structural markup be inherited by child pages? > > To my mind, wicket:extend/wicket:child is just a convenience feature, to > save us from having to create child pages as page/panel pairs. > > jk > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13609607 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
Don't worry, I won't change the old stuff. I just wanted to say that it would have been nice to just override some methods of the old class to change its behaviour. Now, I ended up duplicating most of the old 270-line method into a bunch of smaller methods for better extensibility. I won't use child as an alias, as this would probably change too much of the old implementation. But yes, it is possible to just rename child to abstract and extend to implement without giving any IDs as null is a valid one (so using it as an alias would be possible if needed/wanted). To give a short progress report: I am halfway there ;) Chris Colman wrote: > >> 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
Re: Wicket namespace?
Sure, dtd = old way, xsd = new way. But sadly, there is no official XHTML 1.0 Schema to extend (yet). However, there are two candidates for the future: http://www.w3.org/TR/xhtml1-schema/ (work in progress) and http://www.w3.org/TR/xhtml-modularization/ (working draft). Hence, the only way to extend xhtml right now is by means of a DTD. -- stefan Will Jackson-2 wrote: > > I know you were not saying that it's not supported. I was assuming that it > was not supported because I can't find a public url for that supports it > :) > > afaik extending the dtd is really just adding another dtd > (http://www.w3.org/TR/1999/xhtml-modularization-19990406/developing.html#sec_6.5.2.). > > as far as the schema is concerned anything that can be done in a dtd can > be done in a more elegant manner in an xsd (dtd = old way, xsd = new way). > still curious why there isn't a public url that is published somewhere on > it's use :( > > Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > I didn't say it's not supported, I was just asking. And I don't think you > have to use 2 DTDs. I think it rather is an extension of the standard > XHTML > DTD (that's why it is a DTD and not an XML schema). > > -- Stefan > > > > Will Jackson-2 wrote: >> >> Thanks for the info... hmmm... I wonder why it is not supported? I would >> have assumed that they would use a xsd rather than a dtd. How would this >> be used? Using multiple dtds can get messy (not to mention they may cause >> issues in Internet Exploder). >> >> >>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> >> >> >> Better: >> >> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xmlns:wicket="http://wicket.apache.org"; >> xsi:schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd >> http://wicket.apache.org/someWicketSchema"; >> xml:lang="en"> >> >> Stefan Fußenegger wrote: >> I was asking myself the same a while ago. Today I found a file named >> wicket-xhtml1-strict.dtd in the SVN. You can find it at >> http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd >> >> >> But I don't know whether this file is supported or not, as I haven't >> found >> anything in the docs. Does somebody know more? >> >> Regards, Stefan >> >> >> >> Frank Bille-2 wrote: >>> >>> There is no schema for it if thats what you mean. >>> >>> But you can set the namespace to wicket:xmlns="http://wicket.apache.org"; >>> >>> Frank >>> >>> On Nov 5, 2007 10:42 PM, Will Jackson wrote: >>> >>>> no one knows what the Wicket namespace is? >>>> >>>> Will Jackson wrote: Is there a Wicket xhtml >>>> namespace that will work with Eclipse content assist? I searched the >>>> forums, >>>> but can't find anything. >>>> >>>> __ >>>> Do You Yahoo!? >>>> Tired of spam? Yahoo! Mail has the best spam protection around >>>> http://mail.yahoo.com >>>> >>>> __ >>>> Do You Yahoo!? >>>> Tired of spam? Yahoo! Mail has the best spam protection around >>>> http://mail.yahoo.com >>>> >>> >>> >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> ______ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> > > > - > --- > Stefan Fußenegger > http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > -- > View this message in context: > http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597735 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Wicket-namespace--tf4753975.html#a13602619 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket namespace?
In deed, it's an open issue: https://issues.apache.org/jira/browse/WICKET-693 Timo Rantalaiho wrote: > > On Mon, 05 Nov 2007, Stefan Fußenegger wrote: >> I was asking myself the same a while ago. Today I found a file named >> wicket-xhtml1-strict.dtd in the SVN. You can find it at >> http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd >> >> >> But I don't know whether this file is supported or not, as I haven't >> found >> anything in the docs. Does somebody know more? > > I just know that I have used it and sometimes it has helped > me. I had to add the "wicket:" attributes to my editor (IDEA) > by quick fix though, but that's just once per project. > > Your mileage may vary. > > I think that there is a Jira issue about this as well > ("What to do with the Wicket DTD" or something such), so if > you have good ideas put them there :) > > Best wishes, > Timo > > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Wicket-namespace--tf4753975.html#a13602399 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket namespace?
I didn't say it's not supported, I was just asking. And I don't think you have to use 2 DTDs. I think it rather is an extension of the standard XHTML DTD (that's why it is a DTD and not an XML schema). -- Stefan Will Jackson-2 wrote: > > Thanks for the info... hmmm... I wonder why it is not supported? I would > have assumed that they would use a xsd rather than a dtd. How would this > be used? Using multiple dtds can get messy (not to mention they may cause > issues in Internet Exploder). > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> > > Better: > > http://www.w3.org/1999/xhtml"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:wicket="http://wicket.apache.org"; > xsi:schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd > http://wicket.apache.org/someWicketSchema"; > xml:lang="en"> > > Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > I was asking myself the same a while ago. Today I found a file named > wicket-xhtml1-strict.dtd in the SVN. You can find it at > http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd > > > But I don't know whether this file is supported or not, as I haven't found > anything in the docs. Does somebody know more? > > Regards, Stefan > > > > Frank Bille-2 wrote: >> >> There is no schema for it if thats what you mean. >> >> But you can set the namespace to wicket:xmlns="http://wicket.apache.org"; >> >> Frank >> >> On Nov 5, 2007 10:42 PM, Will Jackson wrote: >> >>> no one knows what the Wicket namespace is? >>> >>> Will Jackson wrote: Is there a Wicket xhtml >>> namespace that will work with Eclipse content assist? I searched the >>> forums, >>> but can't find anything. >>> >>> ______ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> >>> __ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> >> >> > > > - > --- > Stefan Fußenegger > http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > -- > View this message in context: > http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597735 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 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 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. 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. 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 >> > 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 directio
Re: Wicket namespace?
I was asking myself the same a while ago. Today I found a file named wicket-xhtml1-strict.dtd in the SVN. You can find it at http://svn.apache.org/repos/asf/wicket/trunk/jdk-1.4/wicket/wicket-xhtml1-strict.dtd But I don't know whether this file is supported or not, as I haven't found anything in the docs. Does somebody know more? Regards, Stefan Frank Bille-2 wrote: > > There is no schema for it if thats what you mean. > > But you can set the namespace to wicket:xmlns="http://wicket.apache.org"; > > Frank > > On Nov 5, 2007 10:42 PM, Will Jackson <[EMAIL PROTECTED]> wrote: > >> no one knows what the Wicket namespace is? >> >> Will Jackson <[EMAIL PROTECTED]> wrote: Is there a Wicket xhtml >> namespace that will work with Eclipse content assist? I searched the >> forums, >> but can't find anything. >> >> __ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> >> __ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Wicket-namespace--tf4753975.html#a13597017 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
but why choose another name? as long as there is only one pair of however named tags, the behaviour wouldn't change at all. It would only extend the current functionality for those who place a second extension point in there html files. But I am not in the core team, but curious to look under the hood. While I would love to see this extension becoming part of wicket, I don't care too much what happens with it as long as I have fun implementing it. ;) And as numerous times mentioned before: This extension still aligns with how class inheritance works in java, you only have to see html files as classes and extension points as (abstract) methods. That's the only conceptual change. But there is still some time left to argue while I am hacking ;) Regards igor.vaynberg wrote: > > On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> well, i thought chris' suggestion to use abstract and override in order >> to >> align it with the java keyword/annotation. I don't care whether it is >> implement or override (but yes, names are important). i think i'll go for >> implement though ... but if it finally becomes part of wicket, it will >> become extend/child anyway, wouldn't it? > > no it would not. > > as mentioned numerous times before, we like how it currently works > because it aligns with how class inheritance works in java and thus is > easy to understand. > > this would be an in-addion-to feature that people may choose to use. > > -igor > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13590818 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
well, i thought chris' suggestion to use abstract and override in order to align it with the java keyword/annotation. I don't care whether it is implement or override (but yes, names are important). i think i'll go for implement though ... but if it finally becomes part of wicket, it will become extend/child anyway, wouldn't it? but let's see what i can do here first. igor.vaynberg wrote: > > the complement to abstract is implement not override... names are > important. > > -igor > > > On 11/5/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> thanks for that advise. >> >> hey chris, keep your fingers crossed. finally you could get your >> wicket:abstract-wicket:override ;) >> >> 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 >> >> > >> >> > >> >> > &g
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 ;) 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 PROTEC
Re: Multiple tags on a single base page?
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 >> this possible new feature ... well, I'll first estimate the time >> necessary >> to do so and see if I can afford it ;) >> >> Regards >> >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
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 this possible new feature ... well, I'll first estimate the time necessary to do so and see if I can afford it ;) Regards - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Thanks for that awesomely fast reply! 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-tf3775143.html To sum it up for those that came across this thread looking for the same answer: there are two different solutions to this kind of problem: 1. without child-extends-tags using "abstract tags" like this: BasePage() { // maybe you want to doublecheck if the returned component has the expected id add(createComponent("left"); add(createComponent("right"); } abstract Component createComponent(String id) 2. using child-extends-tags using fragments in the html of the subclass The obvious disadvantage of the latter is its need for a html page for every page you create. If you only want to add 2 existing panels (or components), you will find yourself copying a template page over and over again that only has two fragments, each with a . Its advantage is, that one can have the contents of both columns on the same page, which is convenient if there is some JS "interaction" between both panels ... of if your html/css designer needs to have both on the same page for proper validation. 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 hope I got it right. Best regards, Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) igor.vaynberg wrote: > > this has been discussed multiple times on this list, search the > archives. the conclusion has always been that what you want can be > accomplished by factory methods on the basepage that generate panels. > > -igor > > > On 11/2/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> Hi folks, >> >> I just stumbled on a situation where it would be useful to have two or >> more >> tags in a base page. Just consider a layout that >> consists >> of the usual footer, header, navigation, and content parts. But now, the >> content should be arranged in two columns, e.g. two different s. >> >> To give a short example, the BasePage.html cloud look like this >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> And the Child.html markup would look like this: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Wouldn't that be a desirable feature? I tried to run the above example >> expecting to get an exception. The second wicket:child/wicket:extend pair >> was happily ignored though. >> >> Best regards, Stefan >> -- >> View this message in context: >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448 >> 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] > > > -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13553489 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple tags on a single base page?
Hi folks, I just stumbled on a situation where it would be useful to have two or more tags in a base page. Just consider a layout that consists of the usual footer, header, navigation, and content parts. But now, the content should be arranged in two columns, e.g. two different s. To give a short example, the BasePage.html cloud look like this And the Child.html markup would look like this: Wouldn't that be a desirable feature? I tried to run the above example expecting to get an exception. The second wicket:child/wicket:extend pair was happily ignored though. Best regards, Stefan -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LoadableDetachableModel and anonymous inner classes - unwanted serialization overhead?
Hi Matej Thanks for your reply. In deed, I declared the LoadableDetachableModel inside the IDataProvider. So the bottom line of your post is, that it is serialized anyway altogether? Are there some docs for wicket serialization around? As I figured out, wicket likes serialization. But so far I wasn't able to find some docs explaining what is serialized and when. If you - or somebody else - would give me the right pointers, I'd start a new page in the wiki, that especially talks about what is serialized and when, what should be transient, how to troubleshoot/debug/optimize serialization, and so forth. I am very interested in the inner workings of wicket and this might be a good starting point to getting into it, so at least for me its worth the effort ;) Matej Knopp-2 wrote: > > Where do you have your LoadableDetachableModel declared? And what kind > of IDataProvider are you talking about? If it is wicket's > IDataProvider than it has to be serializable, because DataView/Table > keep it's reference. > > LoadableDetachableModel is usually declared as anonymous class inside > component/page, which is serialized anyway, so the implicit reference > makes no difference. > > -Matej > > On 10/25/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> Hi folks, >> >> I am quite new to wicket but I already figured out that it deserved its >> name >> ;) Currently, I am playing around with IDataProvider in conjunction with >> LoadableDetachableModels. As far as I understand, the main purpose of >> LoadableDetachableModels is to tune serialization performance. At the >> beginning I looked at the API doc, which suggested using anonymous inner >> classes for detachable models: >> >> >> public IModel model(Object object) { >> return new LoadableDetachableModel() { >> protected Object load() { >> /* snip - (re)load the object */ >> } >> }; >> } >> >> >> However, this might not be suited for serialization, as inner classes >> have >> an implicit reference on their enclosing object - which was the >> IDataProvider implementation in my case. As a consequence the >> IDataProvider >> object (and all its possible fileds!) would be serialized together with >> every serialized LoadableDetachableModel - which would lead to an >> unwanted >> serialization overhead. >> >> Am I missing something here? Like some Wicket serialization voodoo that >> takes care of it? If not, it would be worth mentioning in the API doc and >> probably in the wiki as well (I would take care of the wiki if I get >> green >> lights). >> >> Regards, Stefan >> -- >> View this message in context: >> http://www.nabble.com/LoadableDetachableModel-and-anonymous-inner-classes---unwanted-serialization-overhead--tf4689309.html#a13402266 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/LoadableDetachableModel-and-anonymous-inner-classes---unwanted-serialization-overhead--tf4689309.html#a13403458 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LoadableDetachableModel and anonymous inner classes - unwanted serialization overhead?
Hi folks, I am quite new to wicket but I already figured out that it deserved its name ;) Currently, I am playing around with IDataProvider in conjunction with LoadableDetachableModels. As far as I understand, the main purpose of LoadableDetachableModels is to tune serialization performance. At the beginning I looked at the API doc, which suggested using anonymous inner classes for detachable models: public IModel model(Object object) { return new LoadableDetachableModel() { protected Object load() { /* snip - (re)load the object */ } }; } However, this might not be suited for serialization, as inner classes have an implicit reference on their enclosing object - which was the IDataProvider implementation in my case. As a consequence the IDataProvider object (and all its possible fileds!) would be serialized together with every serialized LoadableDetachableModel - which would lead to an unwanted serialization overhead. Am I missing something here? Like some Wicket serialization voodoo that takes care of it? If not, it would be worth mentioning in the API doc and probably in the wiki as well (I would take care of the wiki if I get green lights). Regards, Stefan -- View this message in context: http://www.nabble.com/LoadableDetachableModel-and-anonymous-inner-classes---unwanted-serialization-overhead--tf4689309.html#a13402266 Sent from the Wicket - User mailing list archive at Nabble.com.