just to clarify, this is not what component queueing is about. the usecase you are describing is more reminiscent of a CMS where you explicitly build out the functionality of being able to move components around on the page. if your friend A wants the search box on the left and your friend B wants it on the right you would not create two different markup files because that doesnt scale, you would define the layout using some data structure in the database and load it. This is what the Brix project was partially about. Even without CMS its not very difficult. You can achieve a lot with panels and a repeating view - where you add panels based on the order you store somewhere. This allows a dynamic number of panels and dynamic order. You can extend this going further by creating a panel that encapsulates the repeating view and dropping it into itself. This is the beginning of a layout manager pattern used by a lot of CMSs and desktop frameworks like Swing, WPF, etc.
component queuing was about making coding easier. its about hierarchy (nesting of components), not layout. we already have it defined in the markup, so why force the dev to redefine it again in java? its called queueing because you "queue" the components to be placed in their correct hierarchy later. essentially you drop them in the queue and at some point later wicket dequeues them when all of their parents are available. the problems i hit while trying to do this is that components can be added and removed from a lot of different places in the lifecycle: for example a component added in the constructor can force dequeuing of others which in term would call oninitialize() and onbeforenreder() on the dequeued components that can potentially queue/dequeue yet more components. this cascade in itself is easy to implement, but wicket's current lifecycle and code around it is not really built to make this usecase easy. if i were to rewrite wicket from scratch with this idea in mind it wouldve been trivial to implement, but working it into the current codebase will require more time than what i have. my work is in the branch for anyone to pick up... -igor On Thu, Dec 19, 2013 at 5:52 AM, Decebal Suiu <[email protected]> wrote: > Hi > > Maybe it's time to say what I think about this feature. > > I read with interest all posts that talk about component queuing. I don't > know if the name is correct and I don't care about this aspect. The problem > is that are some application types (for example SaaS - software as a > service) where the logic for each instance is the same but the layout is > not. In fact I have the same application but with multiple layouts and for > this reason I must coding to change the hierarchy. > > My personal experience with this kind of problem is related to an ecommerce > platform (based of wicket). My first approach for the home page (by example) > was to split the page in small panels that are self explainable: > HeaderPanel, ContentPanel, FooterPanel. In HeaderPanel I put some > components: search, login, logout, menu, ... After I finished my application > two friends of mine want to use my platform. In that moment I realized that > the splitting process of home page give me a nice and clean separation of > concerts, but it is artificially. I ended to move all components from *Panel > in a big page because I can't move the position of search box in my page > without touching my java code. > I learned a lesson: you must using panels only if you want to reuse that > code (as a component) in many parts of application. > > I must admit that many wicket developers work on applications that does't > require a such scenario. In a non SaaS (I don't find a term now) > applications if the client wants the search box on the right sidebar it's > not a big deal for me to move that component in my java code. For that > developers that have one application on many instances, each instance with a > different layout, it's a big deal. > > I see some people on this forum that try to achieve this non trivial > functionality, I see that Igor try to find a solution but encounters some > issues. Maybe the misfortune is that the core developers are not involved in > SaaS applications :) > > In the end, for me, the missing component queueing is not a stopper, it's > not a must have but it's a nice to have feature. It's enough an incomplete > (limited) implementation (but clean) than nothing. > > That's just my two cents. > > Best regards, > Decebal > > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Queueing-components-tp4549759p4663131.html > Sent from the Forum for Wicket Core developers mailing list archive at > Nabble.com.
