end tag not found in panel-div
Hi, I had worked on several projects with 1.3 and now I have changed to 1.4.2 (and now to 1.4.3). After that I have a strange error when I'm using panels: WicketMessage: close tag not found for tag: div id=logo wicket:id=headerLogo. Component: [MarkupContainer [Component id = headerLogo]] This happens within a panel which looks like this: wicket:panel div id=header div id=logo wicket:id=headerLogo h1a href=#wicket:message key=servicesservices/wicket:message/a/h1 pa href=http://xxx.yyy.zzz/;wicket:message key=projectmanagementprojectmanagement/wicket:message/a/p /div div id=menu wicket:id=headerMenu ul li class=current_page_itema href=#Home/a/li lia href=#Item 1/a/li lia href=#Item 1/a/li lia href=#Item 2/a/li li class=lasta href=#Contact/a/li /ul /div /div /wicket:panel If I comment the contents of the div's (which have wicket:id) everything works fine. wicket:panel div id=header div id=logo wicket:id=headerLogo !-- h1a href=#wicket:message key=servicesservices/wicket:message/a/h1 pa href=http://xxx.yyy.zzz/;wicket:message key=projectmanagementprojectmanagement/wicket:message/a/p -- /div div id=menu wicket:id=headerMenu !-- ul li class=current_page_itema href=#Home/a/li lia href=#Item 1/a/li lia href=#Item 1/a/li lia href=#Item 2/a/li li class=lasta href=#Contact/a/li /ul -- /div /div /wicket:panel I'm not sure but I thought that the content of the div's (with wicket:id) will be replaced with the contents of the panel. So I would expect that this should work. (And I thought that I had used it this way on wicket 1.3). Does anybody have an idea? Marc - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: end tag not found in panel-div
so headerLogo is a Panel? you cannot do that, you cannot have markup with wicket:ids inside a tag that you want to be replaced with a panel. -igor On Sat, Oct 24, 2009 at 12:16 AM, Marc Ende mli...@e-beyond.de wrote: Hi, I had worked on several projects with 1.3 and now I have changed to 1.4.2 (and now to 1.4.3). After that I have a strange error when I'm using panels: WicketMessage: close tag not found for tag: div id=logo wicket:id=headerLogo. Component: [MarkupContainer [Component id = headerLogo]] This happens within a panel which looks like this: wicket:panel div id=header div id=logo wicket:id=headerLogo h1a href=#wicket:message key=servicesservices/wicket:message/a/h1 pa href=http://xxx.yyy.zzz/;wicket:message key=projectmanagementprojectmanagement/wicket:message/a/p /div div id=menu wicket:id=headerMenu ul li class=current_page_itema href=#Home/a/li lia href=#Item 1/a/li lia href=#Item 1/a/li lia href=#Item 2/a/li li class=lasta href=#Contact/a/li /ul /div /div /wicket:panel If I comment the contents of the div's (which have wicket:id) everything works fine. wicket:panel div id=header div id=logo wicket:id=headerLogo !-- h1a href=#wicket:message key=servicesservices/wicket:message/a/h1 pa href=http://xxx.yyy.zzz/;wicket:message key=projectmanagementprojectmanagement/wicket:message/a/p -- /div div id=menu wicket:id=headerMenu !-- ul li class=current_page_itema href=#Home/a/li lia href=#Item 1/a/li lia href=#Item 1/a/li lia href=#Item 2/a/li li class=lasta href=#Contact/a/li /ul -- /div /div /wicket:panel I'm not sure but I thought that the content of the div's (with wicket:id) will be replaced with the contents of the panel. So I would expect that this should work. (And I thought that I had used it this way on wicket 1.3). Does anybody have an idea? Marc - 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: end tag not found in panel-div
Hi Igor, ah, you're completly right. I have forgotten to remove the wicket:message-tags from the panels after seperating them. Thanks for the hint! Have a nice saturday. Marc Igor Vaynberg schrieb: so headerLogo is a Panel? you cannot do that, you cannot have markup with wicket:ids inside a tag that you want to be replaced with a panel. -igor On Sat, Oct 24, 2009 at 12:16 AM, Marc Ende mli...@e-beyond.de wrote: Hi, I had worked on several projects with 1.3 and now I have changed to 1.4.2 (and now to 1.4.3). After that I have a strange error when I'm using panels: WicketMessage: close tag not found for tag: div id=logo wicket:id=headerLogo. Component: [MarkupContainer [Component id = headerLogo]] This happens within a panel which looks like this: wicket:panel div id=header div id=logo wicket:id=headerLogo h1a href=#wicket:message key=servicesservices/wicket:message/a/h1 pa href=http://xxx.yyy.zzz/;wicket:message key=projectmanagementprojectmanagement/wicket:message/a/p /div div id=menu wicket:id=headerMenu ul li class=current_page_itema href=#Home/a/li lia href=#Item 1/a/li lia href=#Item 1/a/li lia href=#Item 2/a/li li class=lasta href=#Contact/a/li /ul /div /div /wicket:panel If I comment the contents of the div's (which have wicket:id) everything works fine. wicket:panel div id=header div id=logo wicket:id=headerLogo !-- h1a href=#wicket:message key=servicesservices/wicket:message/a/h1 pa href=http://xxx.yyy.zzz/;wicket:message key=projectmanagementprojectmanagement/wicket:message/a/p -- /div div id=menu wicket:id=headerMenu !-- ul li class=current_page_itema href=#Home/a/li lia href=#Item 1/a/li lia href=#Item 1/a/li lia href=#Item 2/a/li li class=lasta href=#Contact/a/li /ul -- /div /div /wicket:panel I'm not sure but I thought that the content of the div's (with wicket:id) will be replaced with the contents of the panel. So I would expect that this should work. (And I thought that I had used it this way on wicket 1.3). Does anybody have an idea? Marc - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: I believe all those null-checks of request target can be omited in user code if fallback components would provide fake implementation of AjaxRequestTarget instead of passing null. Does it make sense? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
I think it absolutely makes sense (for a future release of wicket). having a NullObject instance of AjaxRequestTarget would not waste a lot of cpu cycles at all, at least not how i use it. the only thing i do with the object is call .addComponent() and then refering a already-initialized variable. how likely is it that the object is in fact null? its 5% of users who have javascript disabled. so this would affect only a small amount of requests. from a jvm perspective calling methods with empty bodys very often is not something expensive. they will get inlined by the hotspot compiler and be effectively free. (i am not 100% sure if this also applys to polymorphism chains.) from a clean-code prespective it is often considered a code smell to have a lot of null checks. in your example providing a FakeDatabaseConnection that throws an UnsrupportedOperationException(you have no database!) is better than seeing a null pointer exception. Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: I believe all those null-checks of request target can be omited in user code if fallback components would provide fake implementation of AjaxRequestTarget instead of passing null. Does it make sense? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
then you'll have to make check like if (target instanceOf
NullAjaxRequestTarget) {return;} which is not better than before
El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do
with the object is call .addComponent() and then refering a
already-initialized variable.
how likely is it that the object is in fact null? its 5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is
not something expensive. they will get inlined by the hotspot compiler
and be effectively free. (i am not 100% sure if this also applys to
polymorphism chains.)
from a clean-code prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException(you have no database!) is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target
which does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you
application does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in
user code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
-
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: I18N for bookmarkable urls
Hi folks,
Since my app will be english and german aswell, that is something I need
too. I tried to mount and unmount my pages
when the locale changes from german to english or vice versa.
I tried using ResourceModel Strings for the urls, but it's not working
the way I want it to be. And it would be a massive amount of code for
something that seems to be so simple.
The problem is, that I want both urls to be accessed via the url like in
the example:
http://xxx/impressum
and
http://xxx/imprint
should be accessible not depending on a specific locale setting.
(Perhaps the locale should change to english or german depending on the
url when accessed via a browser bookmark with no session)
The problem is, that you can mount a class multiple times, but for
creating the BookmarkablePageLinks the first one mounted will be used
for the link. (tested with wicket 1.4.3).
Wouldn't it be cool to have such a mechanism which uses the Locale
setting to generate links and mount pages.
For example (Just pseudo code):
.mount(
new HybridUrlCodingStrategy(
impressum, ImprintPage.class, Locale.GERMAN)
);
.mount(
new HybridUrlCodingStrategy(
imprint, ImprintPage.class, Locale.ENGLISH)
);
And when you then generate a url you could use:
add(new BookmarkablePageLinkVoid(
bookmarked,
ImprintPage.class,
getSession().getLocale())
);
That way both urls would be accessible if bookmarked.
And the user gets the url generated in his locale while browsing through
the app.
Is there a cool(=easy) way to do that or will it lead to
a massive code section that mounts and unmounts pages on locale change?
Bernhard
Ilja Pavkovic schrieb:
Hi,
as we need some SEO optimization I want to provide the following bookmarkable
pages:
http://xxx/impressum
http://xxx/imprint
the native approach would be somethink like:
mountBookmarkablePage(imprint, ImprintPage.class);
mountBookmarkablePage(impressum, ImprintPage.class);
This looks ugly but works.
Now I don't know how to create a bookmarkable links having an url in the
expected language.
if( getLocale().equals(Locale.GERMAN)) {
//create http://xxx/impressum
} else {
// http://xxx/imprint
}
Obviously the following code does not help:
add(new BookmarkablePageLink(link, ImprintPage.class));
Does anyone have a good idea?
Best regards,
Ilja Pavkovic
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Hi all,
IMHO Vladimir has made a reasonable suggestion.
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
I don't think he meant a *complete* no-op request target, just the
method addComponent() would be a no-op. The fake request target will
rerender the complete page as any other standard request would do.
BTW why don't we get rid of all those AjaxFallback... components and
just let *all* Ajax... components support use of a standard HTML request
as fallback?
Regards
Sven
Martin Grigorov wrote:
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
then you'll have to make check like if (target instanceOf
NullAjaxRequestTarget) {return;} which is not better than before
El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do
with the object is call .addComponent() and then refering a
already-initialized variable.
how likely is it that the object is in fact null? its 5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is
not something expensive. they will get inlined by the hotspot compiler
and be effectively free. (i am not 100% sure if this also applys to
polymorphism chains.)
from a clean-code prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException(you have no database!) is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target
which does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you
application does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in
user code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Wizard Functionality (Extensions)
Hi James, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Wizard Functionality (Extensions)
I am using Ajax but not adding wizard to target. I will play with that. Thank you for the suggestion. Sent from my iPhone On Oct 24, 2009, at 8:32, Sven Meier s...@meiers.net wrote: Hi James, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - 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: Wicket Wizard Functionality (Extensions)
Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - 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: When NOT to use models ?
Hi Martin,
I saw the same type of behavior you are talking about with
LoadableDetachableModels not detaching but AbstractReadOnlyModel's
working properly.
What I found was that I was instantiating my LDM's as private variables
in my custom components but that they were not being detached. In this
case you need to programatically register
your non default models to participate in the detachment process. See
the Wiki here for an example:
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s
For your option 3 I would say you should create a custom IModel
implementation that is aware of your caching strategy so that your
Component's don't need to care about how the data is loaded.
Your implementation could hold a Map of all related models and update
according to your rules or better yet build a service that does the
caching and dirty detection and then just have the LDM source the cell
value from the service. Something like:
new LoabableDetachableModel () {
protected CellValue load () {
return cellService.getValue (row, col);
}
}
Regards,
Mike
evaluated only one time per render can be done with
LoadableDetachedModel ..
I do not mean LOADED once per render. I mean EVALUATED once per
render. In my understanding LoadableDetachableModel does not guarantee
reset in any particular stage.
can you explain it a littly bit (a link to your original message?)
I mean for rexample I have many models like this:
new AbstractReadOnlyModelString() {
public String getObject() {
// evaluate message with some logic
return message;
}
}
Furthermore, I have several components that, say, depend on this
value. This getObject() will be called many times durung render and
the logic will be evaluated many times.
If I make it detachable it will yes be detached but I am not sure that
the detaching is guaranteed at some specific point in request cycle?
To make my use case more clear I will give an example: say I have a
wicket page with a panel that contains a table with columns rows and y
rows. Furthermore, let's assume it is a spreadsheet emulator: you can
write formulas into the cells that depend on the other cells which
means that the value of each cell is recursively evaluated dependent
on the other cell's values.
Requirements:
1. During render time each cell's model value should be cached once it
has been evaluated (we do not want to recurse many times to fetch the
same value).
2. If the value of any cell changes, all the dependent cells should be
(for example) ajax refreshed and re-evaluated. For simplicity, we
could re-set the cache of all models when change occurs. And
redraw-all.
3. We want to reset cache ONLY if change occurs.
In my understanding requirement 3 cannot be directly reached with
detachable models.
**
Martin
Re: Wicket Wizard Functionality (Extensions)
Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
i18n and resource bundles (wicket wiki)
Hi, on the wicket-wiki (http://cwiki.apache.org/WICKET/i18n-and-resource-bundles.html) I've found a point that won't work. Below the point Load resources dynamically for a component there is the first alternative using ...PackageResource.get(MyComponent.class, Mycomponent.properties)... I've tried that to load properties but it doesn't work. The reason is that the PackageResource calls their accept method internally. This loads a PackageResourceGuard from the Application. But this PackageResourceGuard has a list of blocked extensions: java, class and properties. If you make this call above it'll result in a PackageResourceBlockedException. marc - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Absolute static file references
Have another question about serving up CSS (JS, img, etc) files statically:
a) I'd like to have the option to serve my CSS up statically via an apache
proxy. I'd also like to avoid serving CSS requests up via the wicket filter
- even if served up by Jetty - as I think it will scale just a bit better
...
b) With my current URL mounts, many pages with different base URLs refer to
the same CSS file. Consequently, a relative URL for the common CSS files as
referenced in the master template won't work since the CSS file would be
looked up relative to each different URL mount point.
Does that makes sense? So, I would like to create a simple, absolute
reference mechanism for my static CSS, image or other files (without
hardcoding).
I'm not as knowledgeable about the way that components are mapped to wicket
tags, how to add my own tags or even how to create my own components (other
than Panels of course). Does the approach below adhere to the wicket way?
It feels a bit manual ... and I'm not fond of the static WEB_CONTEXT
assignment - but I don't see an elegant/efficient way to get it from within
the Page or the AbstractBehavior on a per request basis.
Just looking for a bit of advice.
Does the WIKI have some detailed docs that really get into the nitty gritty
of low-level component and tag design? IE: Details of ComponentTag,
MarkupElement, WicketTag,
On the other hand, is there any strong advice to put custom CSS, image and
JS files in the classpath and reference ala wicket or is my approach
perfectly reasonable here. An alternate goal of mine to keep custom
components/solutions to a minimum.
Thanks in advance,
-Luther
*MARKUP IN:*
head
link wicket:id=head.link rel=stylesheet
href=style/default/main.css/
/head
*MARKUP OUT:*
head
link rel=stylesheet href=*/portal/*style/default/main.css/
/head
*JAVA*
final static String WEB_CONTEXT =
WebApplication.get().getServletContext().getContextPath();
protected DefaultPageTemplate()
{
//
http://www.mkyong.com/wicket/how-to-dynamic-add-attribute-to-a-html-tag-in-wicket/
final WebMarkupContainerWithAssociatedMarkup cssLink = new
WebMarkupContainerWithAssociatedMarkup(head.link);
add(cssLink);
cssLink.add(new AbstractBehavior()
{
private static final long serialVersionUID = 1L;
@Override
public void onComponentTag(final Component component,
final ComponentTag tag)
{
String href = tag.getAttribute(href);
href = WEB_CONTEXT + / + href;
tag.put(href, href);
}
});
}
RE: Wicket Wizard Functionality (Extensions)
Thanks for the info Sven. I assume by Ajax-ify you mean to create a new implementation that mirrors WizardButton but extends AjaxButton instead of just Button? Also, our code base is currently on 1.4.1, I noticed 1.4.3 (stable?) is released but the main Apache Wicket Page hasn't been updated? What are your thoughts on upgrading directly to 1.4.3, or should we stick with a 1.4.2 upgrade? J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 11:35 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - 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 - 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: Proposal: Fake implementation of AjaxRequestTarget instead of null
On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier s...@meiers.net wrote:
I don't think he meant a *complete* no-op request target, just the method
addComponent() would be a no-op. The fake request target will rerender the
complete page as any other standard request would do.
this is not possible. all public contracts of the request target have
to be properly implemented. eg if a component was added it should be
returned by getcomponents(), also any registered listeners have to be
notified, etc.
i really dont understand the point of this change. if you have a fake
ajaxrequesttarget then the code for a fallback is essentially a noop,
so your app is broken in fallback.
most of the code i have written that utilizes the fallback
functionality looks like this:
onclick(target) {
if (target==null) {
setresponsepage(new editpage(...));
} else {
setupInp+laceEditPanel();
}
}
the workflows are divergent.
-igor
BTW why don't we get rid of all those AjaxFallback... components and just
let *all* Ajax... components support use of a standard HTML request as
fallback?
Regards
Sven
Martin Grigorov wrote:
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
then you'll have to make check like if (target instanceOf
NullAjaxRequestTarget) {return;} which is not better than before
El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do with
the object is call .addComponent() and then refering a already-initialized
variable.
how likely is it that the object is in fact null? its 5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is not
something expensive. they will get inlined by the hotspot compiler and be
effectively free. (i am not 100% sure if this also applys to polymorphism
chains.)
from a clean-code prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException(you have no database!) is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target which
does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you application
does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in user
code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
-
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
-
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: Proposal: Fake implementation of AjaxRequestTarget instead of null
Nothing broken on this side of the fence:
onclick(target) {
deleteRow();
if (target==null) {
// don't bother
} else {
target.addComponent(table);
}
}
Sven
Igor Vaynberg wrote:
On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier s...@meiers.net wrote:
I don't think he meant a *complete* no-op request target, just the method
addComponent() would be a no-op. The fake request target will rerender the
complete page as any other standard request would do.
this is not possible. all public contracts of the request target have
to be properly implemented. eg if a component was added it should be
returned by getcomponents(), also any registered listeners have to be
notified, etc.
i really dont understand the point of this change. if you have a fake
ajaxrequesttarget then the code for a fallback is essentially a noop,
so your app is broken in fallback.
most of the code i have written that utilizes the fallback
functionality looks like this:
onclick(target) {
if (target==null) {
setresponsepage(new editpage(...));
} else {
setupInp+laceEditPanel();
}
}
the workflows are divergent.
-igor
BTW why don't we get rid of all those AjaxFallback... components and just
let *all* Ajax... components support use of a standard HTML request as
fallback?
Regards
Sven
Martin Grigorov wrote:
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
then you'll have to make check like if (target instanceOf
NullAjaxRequestTarget) {return;} which is not better than before
El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do with
the object is call .addComponent() and then refering a already-initialized
variable.
how likely is it that the object is in fact null? its 5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is not
something expensive. they will get inlined by the hotspot compiler and be
effectively free. (i am not 100% sure if this also applys to polymorphism
chains.)
from a clean-code prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException(you have no database!) is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target which
does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you application
does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in user
code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
-
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
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Wizard Functionality (Extensions)
Yes, you can implement your own button bar which adds AjaxFormSubmitBehavior to the normal wizard buttons. Sven Corbin, James wrote: Thanks for the info Sven. I assume by Ajax-ify you mean to create a new implementation that mirrors WizardButton but extends AjaxButton instead of just Button? Also, our code base is currently on 1.4.1, I noticed 1.4.3 (stable?) is released but the main Apache Wicket Page hasn't been updated? What are your thoughts on upgrading directly to 1.4.3, or should we stick with a 1.4.2 upgrade? J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 11:35 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.3 Released!
Thanks! giovanni Resources are limited, Imagination is unlimited. From: Igor Vaynberg igor.vaynb...@gmail.com To: users@wicket.apache.org; d...@wicket.apache.org; annou...@wicket.apache.org Sent: Sat, October 24, 2009 12:12:55 AM Subject: Wicket 1.4.3 Released! release tag: https://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.3 download: http://www.apache.org/dyn/closer.cgi/wicket/1.4.3 changelog: https://issues.apache.org/jira/browse/WICKET/fixforversion/12314250 ( full release notes below ) maven: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4.3/version /dependency thank you. -igor ps. our website has not yet been updated with the release announcement, something is broken with the confluence publishing plugin. --- Release Notes - Wicket - Version 1.4.3 ** Bug * [WICKET-2348] - always insert encoding in http response header * [WICKET-2436] - invalid DataTable markup breaks table layout * [WICKET-2497] - AutoComplete textfield ignores visible property within hierarchy. * [WICKET-2501] - BaseWicketTester clickLink calls onBeginRequest two times. * [WICKET-2505] - Button.onSubmit javadoc is misleading * [WICKET-2506] - Regression: Could not find child with id: ID in the wicket:enclosure for non-component tag * [WICKET-2507] - Inconsistent resource path using wicket:link and HeaderContributor after second request * [WICKET-2508] - NullPointerException in BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:96) * [WICKET-2513] - wicket:enclosure does not work if child is a container and not a component (regression from 1.4.1) * [WICKET-2516] - Javadoc for Component.getMarkupId is incorrect * [WICKET-2518] - Application_bg.properties property file is incorrectly encoded * [WICKET-2520] - Use of Object instead of generic T in StringAutoCompleteRenderer * [WICKET-2522] - Easy fix suggestion: In BaseWicketTester 'IFormSubmitting' component should be the submitting component, not just a 'Button' * [WICKET-2525] - DatePicker consume too much memory * [WICKET-2527] - wicket:enclosure child attribute search path has changed * [WICKET-2528] - CheckBoxMultipleChoice ignores isDisabled() checks * [WICKET-2530] - Class not found when using OSGI class loader ** Improvement * [WICKET-2344] - Performance improvement: more efficient AnnotProxyFieldValueFactory cache * [WICKET-2459] - Add new German Wicket Book * [WICKET-2511] - Upgrade to SLF4J version 1.5.8 * [WICKET-2524] - Configurable Throttle delay for AutoCompleteBehavior ** Wish * [WICKET-2468] - AjaxLazyLoadPanel do not respect especific projects components configuration * [WICKET-2515] - ModalWindow javadoc improvent - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket Wizard Functionality (Extensions)
Sven, I created my own implementation of a Wizard ButtonBar that adds the AjaxFormSubmittingBehavior to the existing buttons. I am not sure what I need to do in the overridden onSubmit(...) for each of the buttons. My current implementation simply calls wizard.getForm().onFormSubmitted() in each of the onSubmit methods, and haven't added anything to the onError. Is this the appropriate onSubmit behavior for the wizard buttons? J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 11:35 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - 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 - 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: Proposal: Fake implementation of AjaxRequestTarget instead of null
In case of AjaxFallback components you would construct them anyway.
Martin Grigorov wrote:
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
then you'll have to make check like if (target instanceOf
NullAjaxRequestTarget) {return;} which is not better than before
El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do
with the object is call .addComponent() and then refering a
already-initialized variable.
how likely is it that the object is in fact null? its 5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is
not something expensive. they will get inlined by the hotspot compiler
and be effectively free. (i am not 100% sure if this also applys to
polymorphism chains.)
from a clean-code prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException(you have no database!) is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target
which does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you
application does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in
user code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Absolute static file references
have you actually hit a scalability problem?
if you are trying to optimize upfront you can use a less invasive
technique. all resource urls in wicekt are served under the
/resources/ virtual folder. you can enable the setting where wicket
will append a last-modified date to the end of each resource url, and
then have an apache-side cache to cache and serve everything under
/resources/.
alternatively see how ContextImage works if you want to serve your own
stuff out of webapp folder.
-igor
On Sat, Oct 24, 2009 at 10:53 AM, Luther Baker lutherba...@gmail.com wrote:
Have another question about serving up CSS (JS, img, etc) files statically:
a) I'd like to have the option to serve my CSS up statically via an apache
proxy. I'd also like to avoid serving CSS requests up via the wicket filter
- even if served up by Jetty - as I think it will scale just a bit better
...
b) With my current URL mounts, many pages with different base URLs refer to
the same CSS file. Consequently, a relative URL for the common CSS files as
referenced in the master template won't work since the CSS file would be
looked up relative to each different URL mount point.
Does that makes sense? So, I would like to create a simple, absolute
reference mechanism for my static CSS, image or other files (without
hardcoding).
I'm not as knowledgeable about the way that components are mapped to wicket
tags, how to add my own tags or even how to create my own components (other
than Panels of course). Does the approach below adhere to the wicket way?
It feels a bit manual ... and I'm not fond of the static WEB_CONTEXT
assignment - but I don't see an elegant/efficient way to get it from within
the Page or the AbstractBehavior on a per request basis.
Just looking for a bit of advice.
Does the WIKI have some detailed docs that really get into the nitty gritty
of low-level component and tag design? IE: Details of ComponentTag,
MarkupElement, WicketTag,
On the other hand, is there any strong advice to put custom CSS, image and
JS files in the classpath and reference ala wicket or is my approach
perfectly reasonable here. An alternate goal of mine to keep custom
components/solutions to a minimum.
Thanks in advance,
-Luther
*MARKUP IN:*
head
link wicket:id=head.link rel=stylesheet
href=style/default/main.css/
/head
*MARKUP OUT:*
head
link rel=stylesheet href=*/portal/*style/default/main.css/
/head
*JAVA*
final static String WEB_CONTEXT =
WebApplication.get().getServletContext().getContextPath();
protected DefaultPageTemplate()
{
//
http://www.mkyong.com/wicket/how-to-dynamic-add-attribute-to-a-html-tag-in-wicket/
final WebMarkupContainerWithAssociatedMarkup cssLink = new
WebMarkupContainerWithAssociatedMarkup(head.link);
add(cssLink);
cssLink.add(new AbstractBehavior()
{
private static final long serialVersionUID = 1L;
�...@override
public void onComponentTag(final Component component,
final ComponentTag tag)
{
String href = tag.getAttribute(href);
href = WEB_CONTEXT + / + href;
tag.put(href, href);
}
});
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Although it is possible I wouldn't recommend authoring certainly different UI
basing on the asynchronisity of the request. For instance I experience
inconvinience when mistakely opening Outlook Web Access in Firefox instead
of MS IE and seeing a bit different non-ajaxy UI.
All the handlers of fallback components in my code perform the same logic
for ajax and non-ajax requests. The only difference is that I have to tell
Wicket what components are invalidated due to changes in data model. I find
it to be a good design style. That sort of information is just a garbage for
the current Wicket rendering algorithm but thing could be different in the
future if you decided to optimize the re-rendering process.
From the other hand I would prefer to just call RequestTarget.isAjax() to
distinguish what interface I should present to the user in case when it is
reasonable different. Checking whether the object is null is much dangerous
and non-self-descriptive. IMHO it is no-no design practice.
Since the number of fallback components is pretty small it is not difficult
to derive from them some project-local components and wrap event handling in
a manner I proposed to guard from NPE. But intention was to improve the
Wicket API not only for that particular case.
igor.vaynberg wrote:
On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier s...@meiers.net wrote:
I don't think he meant a *complete* no-op request target, just the method
addComponent() would be a no-op. The fake request target will rerender
the
complete page as any other standard request would do.
this is not possible. all public contracts of the request target have
to be properly implemented. eg if a component was added it should be
returned by getcomponents(), also any registered listeners have to be
notified, etc.
i really dont understand the point of this change. if you have a fake
ajaxrequesttarget then the code for a fallback is essentially a noop,
so your app is broken in fallback.
most of the code i have written that utilizes the fallback
functionality looks like this:
onclick(target) {
if (target==null) {
setresponsepage(new editpage(...));
} else {
setupInp+laceEditPanel();
}
}
the workflows are divergent.
-igor
BTW why don't we get rid of all those AjaxFallback... components and just
let *all* Ajax... components support use of a standard HTML request as
fallback?
Regards
Sven
Martin Grigorov wrote:
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
then you'll have to make check like if (target instanceOf
NullAjaxRequestTarget) {return;} which is not better than before
El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do
with
the object is call .addComponent() and then refering a
already-initialized
variable.
how likely is it that the object is in fact null? its 5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is
not
something expensive. they will get inlined by the hotspot compiler and
be
effectively free. (i am not 100% sure if this also applys to
polymorphism
chains.)
from a clean-code prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException(you have no database!) is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target
which
does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you
application
does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in
user
code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail:
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
On Sat, Oct 24, 2009 at 5:23 PM, Vladimir K koval...@gmail.com wrote:
Although it is possible I wouldn't recommend authoring certainly different UI
basing on the asynchronisity of the request. For instance I experience
inconvinience when mistakely opening Outlook Web Access in Firefox instead
of MS IE and seeing a bit different non-ajaxy UI.
just because something is not to your liking doesnt mean it should
not be possible, so modify your proposal accordingly.
From the other hand I would prefer to just call RequestTarget.isAjax() to
distinguish what interface I should present to the user in case when it is
reasonable different. Checking whether the object is null is much dangerous
and non-self-descriptive. IMHO it is no-no design practice.
in that case it should just be an onclick() inside which you can do:
if (requestcycle.getrequesttarget() instanceof ajaxrequesttarget) {
}
-igor
Since the number of fallback components is pretty small it is not difficult
to derive from them some project-local components and wrap event handling in
a manner I proposed to guard from NPE. But intention was to improve the
Wicket API not only for that particular case.
igor.vaynberg wrote:
On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier s...@meiers.net wrote:
I don't think he meant a *complete* no-op request target, just the method
addComponent() would be a no-op. The fake request target will rerender
the
complete page as any other standard request would do.
this is not possible. all public contracts of the request target have
to be properly implemented. eg if a component was added it should be
returned by getcomponents(), also any registered listeners have to be
notified, etc.
i really dont understand the point of this change. if you have a fake
ajaxrequesttarget then the code for a fallback is essentially a noop,
so your app is broken in fallback.
most of the code i have written that utilizes the fallback
functionality looks like this:
onclick(target) {
if (target==null) {
setresponsepage(new editpage(...));
} else {
setupInp+laceEditPanel();
}
}
the workflows are divergent.
-igor
BTW why don't we get rid of all those AjaxFallback... components and just
let *all* Ajax... components support use of a standard HTML request as
fallback?
Regards
Sven
Martin Grigorov wrote:
I think he meant wasting CPU cycles for constructing your components
which will be added to no-op ajaxrequesttarget
then you'll have to make check like if (target instanceOf
NullAjaxRequestTarget) {return;} which is not better than before
El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió:
I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do
with
the object is call .addComponent() and then refering a
already-initialized
variable.
how likely is it that the object is in fact null? its 5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is
not
something expensive. they will get inlined by the hotspot compiler and
be
effectively free. (i am not 100% sure if this also applys to
polymorphism
chains.)
from a clean-code prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException(you have no database!) is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target
which
does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you
application
does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in
user
code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
-
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
-
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
--
View
