wicket-el - is this a safe way to hook into wicket?
A few weeks back I made a post about the first version of universal expression language for wicket. Since then it's come quite a way. The initial version hooked into by implementing IMarkupResourceStreamProvider for markup owning MarkupContainers (Panel, Page etc...) and by regenerating markup fragments for markup receiving MarkupContainers (ListView). Unfortunately due to the fact that the EL expressions need to be evaluated on every request this meant a huge performance hit (about 75% less than standard wicket) due to forcing wicket to constantly parse markup on every request cycle. The current evolution of wicket-el hooks in very differently. My first preference was to create a dynamic version of Markup and MarkupFragment that replaces MarkupElements that contain EL expressions with a dynamic version. Unfortuantely this was impossible because I need to subclass Markup (wicket uses a few case of 'instanceof Markup') and Markup has many final methods. And simply wrapping all the MarkupElements isn't possible because RawMarkup is a final class and is also reference inside wicket with 'instanceof'. So the only way I could think of to do it (which I've done and it works) is to create a subclass of Markup (ModifiableMarkup) that takes the original wicket-parsed markup, and adds all it's elements. Then during the onRender phase EL enabled components call ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which internally replaces RawMarkup elements belonging to that compenent with an EL resolved version. This is done just before calling super.onRender(). Sounds ugly but it works and performance is now equal to standard wicket (in some cases can even be a little faster due to not needing PropertyModels). Because the Markup instances are now mutable I can't use wicket's markup cache as it's one per class and ModifiableMarkup.resolve method could easily be called by many threads at once. So I've had to implement caching per thread/class combination. i.e. ELPanel will have a cached instance of Markup for every thread. My question is twofold: 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the purpose of making Markup immutable? From what I can see from browsing wicket source all it achieves is a bit of safety and releasing some resources from the backing XmlTags in the MarkupElements. Is there any other purpose to it? i.e. can you forsee any problems with using a mutable instance of Markup for rendering? 2/ Is the per thread/class caching strategy really safe? The only way I could think it could be broken is if it was possible for the server to suspend a thread mid-render cycle and give another request use of that thread. If that happened the new request would overwrite the markup expressions and the when the old resumed and expressions already resolved would have values from the the request that interrupted it. As far as I'm aware with the work I've done with Jetty and NIO connectors before this will only happen if you ask Jetty to do it while processing the request. Is this a possibility with wicket or can I rely on a complete render cycle to happen uninterrupted before the thread is reused for another request?
Re: Web search functionality
The next step up from LIKE statements is fulltext search. http://devzone.zend.com/article/1304 If you want more advanced functionality and are prepared to spend a bit of time implementing have a look at the Apache Lucene library. If you're using Hibernate there's a neat way to integrate with Lucene if you have a look at the Hibernate Search project. --- On Fri, 10/12/10, Henrique Boregio hbore...@gmail.com wrote: From: Henrique Boregio hbore...@gmail.com Subject: Web search functionality To: users@wicket.apache.org Received: Friday, 10 December, 2010, 11:02 AM I want to add search functionality to my site (think of a classifieds site, something like craigslist where users post items to sell). Currently I am using mysql for storage, and nothing else. Is searching directly at the database via queries the best way? It seems illogical to perform a linear search at a large mysql table using a 'like' statement. I'm sure there's a better way, anyone implemented a successful (fast, memory-friendly) search feature in a web 2.0 site? Thanks. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: A beginner's tutorial
I agree the 'model' is a very powerful concept that needs to be explained properly... However drawing on my own early experiences with with java frameworks I can say that the reasoning for why model's are valuable is difficult to understand until the principals of request lifecycle have been fully explained. The point of a model is to express a dynamic value that is is dependent on the current state of several variables than can change during the course of a single or multiple requests. In the early stages of learning any web front end technology the 'lifecycle' concept is a new one. jcgarciam wrote: Hi, i did a quick walk thru the tutorial and something i think is missing and could help is to explain the concepts of Model and the difference between Static Model and Dynamic Model. I know it may complicate things for students and new comers to wicket programming but i think it worth, (using Page 6 (adding the Datetime to the homepage) as example its good enought to understand it. Hope it helps. On Thu, Aug 5, 2010 at 10:15 AM, H. Turgut Uyar [via Apache Wicket] ml-node+2314844-1121304651-229...@n4.nabble.comml-node%2b2314844-1121304651-229...@n4.nabble.com wrote: Hi, I am a lecturer at the Istanbul Technical University, Computer Engineering Department. One of the courses I teach is Database Management Systems where the students develop a web application using databases as their term project. Until a few years ago we used PHP but then switched to Java in order to be consistent with the course material. Last year we have gone with Wicket as our framework but the students had trouble with finding their way in the documentation. Considering that this is the first course they take after an introductory object-oriented programming course, this year I've decided to prepare a simple tutorial that would teach them how to get started on such a project. The result is on the address: http://www3.itu.edu.tr/~uyar/wicket-tutorial/ There is also a PDF version: http://www3.itu.edu.tr/~uyar/wicket-tutorial/wicket-tutorial.pdf The problem is, I'm a novice Wicket programmer. I would really appreciate all kinds of feedback, especially about the mistakes I might have made in the text or the code. Thanks -- H. Turgut Uyar [hidden email]http://user/SendEmail.jtp?type=nodenode=2314844i=0 [GPG KeyID: 0xEAF45FB8] http://www3.itu.edu.tr/~uyar/ - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2314844i=1 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2314844i=2 -- View message @ http://apache-wicket.1842946.n4.nabble.com/A-beginner-s-tutorial-tp2314844p2314844.html To unsubscribe from Apache Wicket, click herehttp://apache-wicket.1842946.n4.nabble.com/subscriptions/Unsubscribe.jtp?code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDExOTE5MDc4OTQ=.
KonaKart shopping cart integration
I've been looking for a shopping cart solution that I can properly integrate with wicket. There's been a few threads on this list where people have indicated they were building one but as far as I know nothing has ever eventuated. I don't really want to build to whole engine from scratch so I've been looking around and come across konakart. It's partially open source. Meaning the engine itself is closed but it has a complete (and well documented) integration layer. I think this would be a good solution because all the backend functionality is there along with a nice admin panel. The interface is either Java or SOAP (one line of code to switch between the two) which means you can run your cart engine on another server if you want. So what I'm proposing is build a set of front-end wicket components. I'd prefer a fully open source solution but in the free java space this seems to be the easiest solution I can find. I really don't have time to build an engine from the ground up. So before I get going I just wanted to bounce it off the community and see if anyone can think of a better solution? I only just come across brix and I'm still trying to get my head around it. Any comments on whether I should make this brix centric or pure wicket? p.s. If I do build these components then I will release them as LGPL... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
