Re: [Wicket-user] Anti-Wicket?
Hi Jonathan (et al.), Thanks for your post. On 15/05/2007, at 1:17 PM, Jonathan Locke wrote: i don't understand how you can have a component-oriented web framework that generates markup and css without having layout managers. browsers are not consistent enough in the way they render to just position everything absolutely. even if they were consistent, you still couldn't use fixed layouts because fonts vary from platform to platform. what you're asking for doesn't make any sense to me because programmatically specifying the place of all widgets and content, is /exactly what a layout manager does/. Thank you again, you may have pointed out problems with my approach (which, of course, are better to find out earlier rather than later). That said, I don't see why programmatically specifying the place of all widgets and content can't be done in a browser- independent way (compensating for browser differences, even perhaps adjusting font sizes, I don't know) without using a layout manager. To me, a layout manager is something that adapts the layout according to some generalised rules (e.g. a row or column layout manager) to fit the current display area size, and are specifically made to handle resizing of that display area. I am not that interested in resizing, but a static structure derived from the content, styles, and layout data. I guess an example would be a page layout program. I think in pretty much any Web framework, I could have a single custom component on a page, and use the application to generate all the HTML to go into that component and build most (if not all) of the page. I guess I am looking for a framework that would help me generate that HTML programmatically. As I mentioned, I used to do this in PERL, I was looking for something in Java and higher-level. That's just reminded me of the Apache Element Construction Set (ECS) at http://jakarta.apache.org/ecs/. It does something like I think I want in Java but hasn't been updated for a number of years (since 2003) so it lacks the latest HTML constructs (e.g. CSS). my personal opinion (and one of the driving forces behind wicket) is that designers should not code and coders should not design. Sure, that's great for most Web applications. I would hope you could understand though that, perhaps, there were a class of Web applications for which this wasn't the optimal approach. Further, I wasn't suggesting the designers code, but that code was used to generate the whole page (i.e. no template). This doesn't preclude designers from designing the page in another way (e.g. in another part of the application). in any case, i am not aware of other solutions to this problem outside those already mentioned. No problem, I'm thinking that the AJAX Web frameworks like Echo2 or wingS (or one of the others, frameworks like these seem to be popping up everywhere these days) may be the way to go, with a custom component (that I write) that does the rendering for the content I want to render, in the way I want to render it (i.e. data driven). I just need to find which one allows me to do that most easily. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com Skype Name: MrHatken (GMT + 8 Hours!) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Anti-Wicket?
Hello All, Sorry for this somewhat off-topic post, but I am interested in a Web framework that, I guess, does the opposite of Wicket, and I thought, perhaps, you may be the best people to ask. My understanding is that Wicket does great at separating the designer's concerns from the back- end Web application, slotting dynamic content into pre-designed standard Web pages. What I am looking for is a Web framework that does, just about the opposite of this. The entire Web page is produced by the framework (including complex generated CSS layout and lots of content). Of course, I know Wicket can do some (all?) of this, but is it the most appropriate Web framework for this task. Are there any more suitable or better alternatives? My mind wanders back to Perl-based Web development, and libraries that allowed you to develop a full page (as difficult as that was). Can people suggest any more modern Web frameworks that do that? Of course, I want the page to be dynamic because it is going to change significantly depending on the content. This app reverse the balance between dynamic and static page data. Thanks in advance for any suggestions (even Wicket if you think it would do well). Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com Skype Name: MrHatken (GMT + 8 Hours!) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Anti-Wicket?
Hi Igor and Alexandre (and everyone), Wow, thanks of the prompt posts. I'm familiar with GWT (AJAX with client-side application) and Echo2 (AJAX with server-side application) and they do, as you suggest, both use layout managers. In particular, I am considering using Echo2. However, their focus in most only AJAX and less on the layout (at least, for Echo2, as far as I can tell). I am looking more for a full-featured way of doing Web design programmatically, the major focus being on CSS layout perhaps, rather than using some layout manager. I guess an analogy would be between using a layout manager in Java SE, and programmatically specifying the place of all widgets and content. I am interested in the latter, any ideas? I don't wish to make a design that can be customised by CSS, I want to programmatically generate CSS styles to layout the content of each page (as directed by the content). I hope that makes sense. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com Skype Name: MrHatken (GMT + 8 Hours!) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Re: The other side of Wicket ...
Hello Igor (et al.),Thank you for your reply and explanations.the top container of components in wicket is the page. session keeps references to x number of pages for callbacks and backbutton support. so these are only serialized when replication of the session occurs. So the pages are only serialised when the session is serialised for replication. I am not sure how Wicket (or if it is even within Wicket's scope) handles replication/clustering, but if one were using sticking sessions (sessions mapped to the same server in the cluster) then I guess one wouldn't need to serialise the session or pages at all. Does that sound right?components also have models. when the user calls setModelObject() 2nd+ time we clone the model by serialization so that we can version it.Ok thanks, I didn't realise that. I guess you serialise the cloned component model to save space or save to disk (rather than leave the objects in memory)? The models would thus need to be detached (e.g. separate or using a lazyinitproxy) from the full business model. I'm still trying to get my head around what would happen to the full business model if someone hit the back button and went back to a previous component model ...The back button is surely the bane of the Web application developer. So, let me see if I understand correctly (please someone correct me if I am wrong). Sessions are only serialised for replication/clustering (i.e. if one needs to be able to process any request on any server).Pages are only serialised when Sessions are serialised (as above).Models of components (pages, panels, etc.) are serialised when changed (after being set) to handle the back button.So if a Web application has a large business model / service that needs to remain in memory across multiple request-response loops (and as such the application uses sticky sessions) then sessions and pages will not be serialised. If the application saves no previous pages (so the back button won't work) would the application need to worry about serialised component models?So in this case there would be no reason to need injection or lazyinitproxies etc? I can see mostly how this works. However, although others have proclaimed it so, it doesn't seem that elegant or easy to me.if you are going to say something like this you can at least tell us which part of it does nto seem elegant or easy.Firstly, I am sorry I wrote that comment like that, it was late and I was tired. I wasn't trying to be critical I was just remarking that whereas the "front-side" of Wicket (views) seemed to be thought out beforehand, the "back-side" integration seemed to be an "add-on." I guess that is the way with new open source projects as they develop under the public eye, and again I apologise. Secondly, I guess I was also hoping that Wicket would have a more integrated and transparent approach (although I understand that Wicket components are in some sense unmanaged) to maintaining links to business services and larger graphs of business objects. I see now that it probably does as much as most other frameworks (except for the extra work needed for component models as discussed above).I am not sure if there are any Web frameworks that transparently handle mobile sessions automatically (especially when there are dependencies). I know there are many types of Web applications (from very light stateless to very heavy stateful applications) and most of these problems are common to all Web application frameworks. I'm just trying to get a better picture of how Wicket would generally be used to handle each of these situations (although I am more interested in the heavy stateful type of applications at the present time). Thanks again.Cheers,Ashley.--Ashley AitkenPerth, Western Australiamrhatken at mac dot comSkype Name: MrHatken (GMT + 8 Hours!)
Re: [Wicket-user] Re: The other side of Wicket ...
Hi John (et al.),On 05/05/2006, at 7:46 PM, John Patterson wrote:Ashley Aitken wrote: So the pages are only serialised when the session is serialised for replication. I am not sure how Wicket (or if it is even within Wicket's scope) handles replication/clustering, but if one were using sticking sessions (sessions mapped to the same server in the cluster) then I guess one wouldn't need to serialise the session or pages at all. Does that sound right? Pages are also serialized when a new browser window is opened - the current page is cloned (via serialization) and placed in a new PageMap. This would occur, for example, if the user clicks on a link to your site in an email which usually opens the page in a new window. Also when a your page creates a pop-up window explicitly or the user opens a link in a new tab.Ok, thanks for that information. I don't fully understand why wicket needs to clone the page rather than just moving the page into the new page map?I believe Wicket does this so it can operate correctly no matter which path the user choose (e.g. to continue in the new page, to still work in the old page, or both). Cloning (through serialisation) the page makes sure you have two copies of the state. Now, don't take that for the gospel (because as you can see I am just learning) but I believe it to be the case. Cheers,Ashley.--Ashley AitkenPerth, Western Australiamrhatken at mac dot comSkype Name: MrHatken (GMT + 8 Hours!)
Re: [Wicket-user] Re: The other side of Wicket ...
Hello again Igor (et al.),I hope you don't mind me following up your reply. I promise (fingers-crossed) I'll stop after this post ;-)On 05/05/2006, at 2:35 PM, Igor Vaynberg wrote:On 5/4/06, Ashley Aitken [EMAIL PROTECTED] wrote: So the pages are only serialised when the session is serialised for replication. I am not sure how Wicket (or if it is even within Wicket's scope) handles replication/clustering, but if one were using sticking sessions (sessions mapped to the same server in the cluster) then I guess one wouldn't need to serialise the session or pages at all. Does that sound right? almost but not exactly :) if you have fallback in your cluster the session would be replicated from user's node to the backup-buddy node, or multicast to all nodes, or whatever - depending on your fallback strategy. so in this case the session is replicated on every request. but, if you have a fast backplane between cluster nodes this should not be a big deal. Sorry, but you lost me there. Are you saying if one had sticky sessions with fallback clustering then Wicket would still have to replicate the session? I was thinking more that the session would just fail if the server hosting the session failed. Further, I don't believe Wicket does clustering itself (please correct me if I am wrong) so does it conform to some sort of clustering API? Ok thanks, I didn't realise that. I guess you serialise the cloned component model to save space or save to disk (rather than leave the objects in memory)? no, we actually clone by serialization. the Clonable interface in java is a pita and so we chose to clone by serialization. see wicket.util.lang.Object.cloneObject(Object)Clone by serialisation? I guess you mean you serialise and then un/de-serialise. So you don't serialise to save to disk?The models would thus need to be detached ( e.g. separate or using a lazyinitproxy) from the full business model. yes, the models are detached before we clone them.By detach I was thinking more of separating the model objects from some greater set of business objects (which may in effect be, but not specifically be, what you were referring to). I know, however, that Wicket has the notion of a "detachable model."I guess this correspond well to the Hibernate and now JPA notion of detachable objects. If a Wicket page has a customer objects as its model then before that page or model is serialised the customer object could be detached from the persistence manager. I'm still trying to get my head around what would happen to the full business model if someone hit the back button and went back to a previous component model ... in this case we would roll the model and any other changes back to what it was on the page thereby restoring the component hierarchy to what it was before the backbutton was pressed. Ok, you can role back the model that was "versioned" with the page change. However, that would not undo any changes that were possibly made to the greater business model associated with the session.The back button is surely the bane of the Web application developer. yes, especially when building web applications and not web sitesI am starting to think that the more Web applications try to be like desktop application (Web 2.0 and all that) the less we will be able to handle the back button (or that it will even make sense). I don't think the back button can be equivalent to an "undo" type operation?So perhaps this versioning of the models won't be a key feature in the future (for certain types of Web applications - lets call them Web apps with heavy sessions). I am open to opposing views here?So if a Web application has a large business model / service that needs to remain in memory across multiple request-response loops (and as such the application uses sticky sessions) then sessions and pages will not be serialised. If the application saves no previous pages (so the back button won't work) would the application need to worry about serialised component models? i think you misunderstand what the model is. the model is the databinding. it allows the component to retrieve and store data in an abstract way.Sorry if I am not getting this. I thought a model could be a simple String, or a more complex object (or small object graph) like Customer. I thought most components were associated with a model, i.e. the object(s) that they are representing in some way in their view.A databinding, for me at least, would be a mapping between parts of the view and parts of the model but *not* the model itself, an associative map of some kind. That said, I think I know what you mean and there is no need to argue over definition.So in this case there would be no reason to need injection or lazyinitproxies etc?that depends. if you are always going to be careful about looking up the service layer objects and never leaving a reference to them, then yes, you do not need injection or wicket proxies Ok.wicket is a focused
[Wicket-user] The other side of Wicket ...
Howdy All,I've been reading more about Wicket, particularly its integration with non-presentation aspects of an Enterprise application, e.g. the application and persistence layers. I've read about the Wicket-Spring integration, and the LazyInitProxy - where a Wicket session keeps an injected proxy to any dependencies(?). I can see mostly how this works. However, although others have proclaimed it so, it doesn't seem that elegant or easy to me. I'm wondering if people think this is a good solution or Wicket needs more work in this area (not being critical, just asking)? I must say I haven't thought much before how sessions would be managed across each request-response loop. I believe Wicket serialises the session and all the pages cached therein. I've worked with WebObjects and therein a session is sent the awake() message before the request-response loop begins, and the sleep() message after the r-r loop finishes. I guess these inherited methods could include code to serialise the session, but I have never thought how they handle not serialising all the business objects (model) managed by the O/R framework. Maybe they don't serialise the session or pages but just keep them in memory. I believe Wicket does the serialisation, at least in part, to perhaps assist with clustering (processing requests on different servers etc). I am just wondering how other frameworks handle this problem and why it seems more difficult in Wicket? Would Wicket fit in well as a Web presentation layer for an application using EJB3 (including JPA)?Best regards,Ashley.--Ashley AitkenPerth, Western Australiamrhatken at mac dot comSkype Name: MrHatken (GMT + 8 Hours!)
[Wicket-user] Re: The other side of Wicket ...
Hi Vincent (et al.),I'm about 90% finished w/ a Wicket/EJB3 (JBoss) storefront solution for my company to start doing consumer web sales. In my personal opinion, Wicket + EJB3 is the holy grail of Java web development...and I'm not being dramatic. It would be hard to convince me to use another framework, going forward. That's a glowing report for Wicket integration with EJB3.Thanks for explaining how well your application development went. Cheers,Ashley.--Ashley AitkenPerth, Western Australiamrhatken at mac dot comSkype Name: MrHatken (GMT + 8 Hours!)
Re: [Wicket-user] Mailing list archive was: Generating HTML with Wicket?
Hi Rüdiger (et al.), Thanks for your post. On 03/05/2006, at 5:20 PM, Rüdiger Schulz wrote: Ashley Aitken wrote on 03.05.2006 at 07:50: it is hard to follow threads via the archive You're probably using the archive at SF. Take a look at nabble's, I found that to be way better regarding searching and following threads: http://www.nabble.com/Wicket---User-f13976.html Yes, that's a lot better. I see Wicket also has a GMANE (mailing list to news gateway) newsgroups (for those who prefer newsgroups). http://www.gmane.org Thanks again. Cheers, Ashley. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Generating HTML with Wicket?
On 03/05/2006, at 5:42 PM, Timo Stamm wrote:Instead of handling Strings yourself, it is perfectly possible to use ECS or any other lib (like the ones that come with Jetty) for this task.Yes, that was my hope (or that Wicket classes could optionally generate the full HTML). But I am unsure how to inject the HTML into a Wicket page at a particular location. Would I just have something like a a SPAN or DIV tag with a wicket:id and then dynamically put the string generated from ECS or similar in there at run-time using a Label?But I doubt that this integrates well with the rest of the wicket world. Using Panels to generate markup dynamically is quite powerful. I think that Wicket could handle this a bit more elegant, but it really works well enough for most cases.See this article for a very short introduction to using Panels for dynamic markup:http://www.wicket-wiki.org.uk/wiki/index.php/Create_dynamic_markup_hierarchies_using_panelsYes thanks, I have seen that but it doesn't seem like it would scale to generate arbitrary HTML - having a component for every different HTML tag (pair) seems like overkill ;-)Cheers,Ashley.--Ashley AitkenPerth, Western Australiamrhatken at mac dot comSkype Name: MrHatken (GMT + 8 Hours!)
[Wicket-user] Generating HTML with Wicket?
Howdy All,I am new to Wicket, just looking around for an appropriate Web framework to use on my next project. I would like to know if Wicket can (or will shortly be able to) generate HTML elements (as well as doing all the other things it can do). By this I mean something like the old Element Construction Set (ECS) or perhaps even Swinglets.I've seen some discussion of this on the mailing list archive (although it is hard to follow threads via the archive), but it was mainly relating to Wicket possibly auto-generating prototype HTML if a HTML file was not available. I also understand that Wicket usually works with a HTML file and some may suggest using a Wicket panel for each possible element I wish to construct. That may be a possible but it doesn't seem elegant.However, I can't see why Wicket couldn't generate HTML when required, for very dynamic parts of a Web page. Wicket seems to have classes corresponding to most (if not all) HTML elements already.Of course, most dynamic Web pages won't need this, they just want to slot some dynamic content in an already setup HTML template, but I can also see where full dynamic control of the tags and content could be useful. Sorry if I have misunderstood how Wicket works. Any comments, or suggestions, would be most appreciated. Cheers,Ashley.--Ashley AitkenPerth, Western Australiamrhatken at mac dot comSkype Name: MrHatken (GMT + 8 Hours!)
