another idea might be: since wicket:ids are well known you can parse the
markup and only add the components that are present in the markup instead of
adding all of them all the time. you can do this when the user is done
editing his page, so its done only once, and you keep a list of components
you need to add somewhere.
the problem i see with adding isOptional(), etc is that we are adding
something to the core to work around a /debug/ setting. i see this as api
bloat.
-Igor
On 3/8/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
what you could do is that the cms editor doesn't really design the page at
that time. But only configures it. So in a property file
it says what component should be rendered or not.
just and idea..
johan
On 3/8/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
So perhaps I should give you some more context to understand my usecase:
We're using a CMS behind Wicket to serve the HTML templates for all our
pages (the panels are designed by web designers and included in the war file
as usually).
This way our CMS users are able to customize the basic layout and
content of every page and we developers don't have to hassle with columns,
headers, texts and images.
Every page offers its dynamic parts (mostly one main and several
additional components) via well known wicket:ids. To position a component on
the template the CMS editor just puts a <div wicket:id="history"/> into the
template and accordingly the history panel is included.
Now comes the problem: If the CMS editor decides to omit a component
from the page (perhaps to save space) the rendering check will bark :(.
I thought I could just call #renderer() on my top level panels by
myself, but regretfully this will throw a MarkupException if the panel was
already renderer.
Sven
I think it is. But if Sven has a good use case we should see whether
we can support it. Though you can also use AOP as a breakout I
think...
Eelco
On 3/7/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
a strategy for a /debug/ check. dont you think this is a little
overkill?
:)
-Igor
On 3/7/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
Sven is the man to answer that I guess. I can imagine that he is
providing a full component tree and that the designer chooses which
part of that tree should actually be used. Quite dangerous, but
might
be usefull at times. Another thing we might consider is to hide the
check itself behind a strategy interface.
Eelco
On 3/7/06, Juergen Donnerstag < [EMAIL PROTECTED]>
wrote:
I haven't understood the use case yet. I can read the request but
haven't understood why it is necessary. Why should the markup
vary
from the java code?
Juergen
On 3/7/06, Johan Compagner < [EMAIL PROTECTED] > wrote:
yeah, we could have a method isOptional() {return false;} that
can be
overridden if really needed.
On 3/7/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
I wouldn't be against a flag that says the whether component
has to
be
rendered. The default should be true, in which case nothing
changes
from the way things are now, but if the flag returns false,
it
would
be ignored by the components check.
What do the other devs think of this?
Eelco
On 3/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I'm aware of
IDebugSettings#componentUseCheck.
But with this setting I would loose the rendering check
globally
:(.
I'd rather keep the check for most of my components.
Sven
One thing you can do is turn of the render check. Would
that
suffice?
Eelco
On 3/7/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
I'm in need of 'optional' components, i.e. they exist in
Java
code
but the
web designer is allowed to omit them in the HTML template.
Currently I'm using a base class (named OptionalPanel)
that
cooperates with
the page: In Page#renderAll() all appropriate children are
marked
as
being
rendered, if not already rendered by Wicket.
I'm not happy with the implementation though, as it
seems to
me
more
like a
hack :(.
What do you think - could Wicket include a solution for
this?
A
tag
interface? Or an #isOptional() on Component?
Thanks
Sven
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting
language
that extends applications into web and mobile media.
Attend
the
live
webcast
and join the prime developer group breaking into this
new
coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting
language
that extends applications into web and mobile media.
Attend the
live
webcast
and join the prime developer group breaking into this new
coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting
language
that extends applications into web and mobile media. Attend
the
live
webcast
and join the prime developer group breaking into this new
coding
territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting
language
that extends applications into web and mobile media. Attend
the
live
webcast
and join the prime developer group breaking into this new
coding
territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting
language
that extends applications into web and mobile media. Attend the
live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the
live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
