You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Fridolin Jackstadt <fr...@gmail.com> on 2013/12/12 21:51:52 UTC
Re: Queueing components?
This post has NOT been accepted by the mailing list yet.
I liked the idea of component queuing, unfortunately it was never available.
Since i needed a mechanism that fullfills a similiar task i did this small
library:
https://github.com/wicket-acc/wicket-autowire
I would be happy if one of the core team would check it out!
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Queueing-components-tp4549759p4662963.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Queueing components?
Posted by Fridolin Jackstadt <fr...@gmail.com>.
Hi,
Thanks for your reply! This is basically the idea (i also in the updated
the readme):
Apache Wicket is a great framework for web applications, and the decoupling
of logic and layout is good, with one limitation: You have to "rebuild" the
component hierarchy of your markup in your java code. Using this library
makes your life easier:
- You don't have to add a component to its parent yourself.
- You can skip a component in the markup if you want to.
- You can simply have differenty styles with completely different
component positions.
- You dont have to call the constructor of the component and pass the
id as a string.
Greetings, F. Jackstadt
On Monday, December 16, 2013, Martin Grigorov-4 [via Apache Wicket] wrote:
> Hi,
>
> Thanks for sharing!
>
> I didn't have much time to investigate your code but the approach looks
> interesting.
> I'll also have to refresh myself what problems Igor faced while working on
> this task.
> You can help some more by adding some explanation to the README about the
> idea of the implementation and some javadocs to the tests.
> I have some TODOs for Wicket 7 (tickets related to request mappers) but I
> hope to get back to your idea soon.
>
> Martin Grigorov
> Wicket Training & Consulting
>
>
> On Thu, Dec 12, 2013 at 10:51 PM, Fridolin Jackstadt <[hidden email]<http://user/SendEmail.jtp?type=node&node=4663048&i=0>>wrote:
>
>
> > This post has NOT been accepted by the mailing list yet.
> > I liked the idea of component queuing, unfortunately it was never
> > available.
> > Since i needed a mechanism that fullfills a similiar task i did this
> small
> > library:
> >
> > https://github.com/wicket-acc/wicket-autowire
> >
> > I would be happy if one of the core team would check it out!
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/Queueing-components-tp4549759p4662963.html
> > Sent from the Forum for Wicket Core developers mailing list archive at
> > Nabble.com.
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/Queueing-components-tp4549759p4663048.html
> To unsubscribe from Queueing components?, click here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4549759&code=ZnJpZG8zN0BnbWFpbC5jb218NDU0OTc1OXwtMTA0MzgwODYwOQ==>
> .
> NAML<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Queueing-components-tp4549759p4663115.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Queueing components?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Thanks for sharing!
I didn't have much time to investigate your code but the approach looks
interesting.
I'll also have to refresh myself what problems Igor faced while working on
this task.
You can help some more by adding some explanation to the README about the
idea of the implementation and some javadocs to the tests.
I have some TODOs for Wicket 7 (tickets related to request mappers) but I
hope to get back to your idea soon.
Martin Grigorov
Wicket Training & Consulting
On Thu, Dec 12, 2013 at 10:51 PM, Fridolin Jackstadt <fr...@gmail.com>wrote:
> This post has NOT been accepted by the mailing list yet.
> I liked the idea of component queuing, unfortunately it was never
> available.
> Since i needed a mechanism that fullfills a similiar task i did this small
> library:
>
> https://github.com/wicket-acc/wicket-autowire
>
> I would be happy if one of the core team would check it out!
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Queueing-components-tp4549759p4662963.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>
Re: Queueing components?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <de...@asf.ro> 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.
Re: Queueing components?
Posted by Decebal Suiu <de...@asf.ro>.
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.