Re: Problem closing a ModalWindow when used through an IFrame
Hi Matej! Have you been able to reproduce this problem? DM 2007/11/1, Deepak Mahavishnu [EMAIL PROTECTED]: Hi Matej! And thanks for a quick response! I opened a jira issue related to this. The quick start is very straight forward: Just create a html page with this source: html body iframe src= http://www.wicket-library.com/wicket-examples/ajax/modal-window.1; width=100% height=100%/iframe /body /html And then open Show modal dialog with panel and try to close the dialog. Mahavishnu 2007/11/1, Matej Knopp [EMAIL PROTECTED]: The modal window probably won't work well when paced in a page that is loaded in iframe. Still, if you can provide a quickstart assigned to a JIRA entry I will take a look if there is a quick fix for your problem. -Matej On 11/1/07, Deepak Mahavishnu [EMAIL PROTECTED] wrote: Hello! I'm doing some POC testing to find out how a wicket application could be used through an IFrame and noticed that closing of a ModalWindow fails. My setup: Application A: -a dummy html page that has an IFrame -the contents of the IFrame is requested from Application B iframe src=http://localhost:8080/mywicketapp/app/; width=100% height=500/iframe Application B: -a Wicket application that uses a ModalWindow -deployed to tomcat: http://localhost:8080/mywicketapp/ Problem: The ModalWindow is not closed when OK ( or Cancel ) button is clicked when Application B is used throug IFrame of Application A. OK button performs the actual action (in my case deletes an item from a list) but is not closed after the execution of the action. Closing of the ModalWindow works normally when Application B is not used through an IFrame. Any suggestions how this could be solved? Or is the usage through an IFrame a bad idea from start? Any help is appreciated! Mahavishnu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem closing a ModalWindow when used through an IFrame
Not yet, and I'm not sure I'm going to soon. Supporing modal window in iframe might be too big change for 1.3, because of they way modal window internally works. Btw. you example is broken, because you load page from wicket-library.com, which is different domain than where the iframe is. That will not work at all, since it would be cross-domain scripting, which browsers don't allow. -Matej On 11/4/07, Deepak Mahavishnu [EMAIL PROTECTED] wrote: Hi Matej! Have you been able to reproduce this problem? DM 2007/11/1, Deepak Mahavishnu [EMAIL PROTECTED]: Hi Matej! And thanks for a quick response! I opened a jira issue related to this. The quick start is very straight forward: Just create a html page with this source: html body iframe src= http://www.wicket-library.com/wicket-examples/ajax/modal-window.1; width=100% height=100%/iframe /body /html And then open Show modal dialog with panel and try to close the dialog. Mahavishnu 2007/11/1, Matej Knopp [EMAIL PROTECTED]: The modal window probably won't work well when paced in a page that is loaded in iframe. Still, if you can provide a quickstart assigned to a JIRA entry I will take a look if there is a quick fix for your problem. -Matej On 11/1/07, Deepak Mahavishnu [EMAIL PROTECTED] wrote: Hello! I'm doing some POC testing to find out how a wicket application could be used through an IFrame and noticed that closing of a ModalWindow fails. My setup: Application A: -a dummy html page that has an IFrame -the contents of the IFrame is requested from Application B iframe src=http://localhost:8080/mywicketapp/app/; width=100% height=500/iframe Application B: -a Wicket application that uses a ModalWindow -deployed to tomcat: http://localhost:8080/mywicketapp/ Problem: The ModalWindow is not closed when OK ( or Cancel ) button is clicked when Application B is used throug IFrame of Application A. OK button performs the actual action (in my case deletes an item from a list) but is not closed after the execution of the action. Closing of the ModalWindow works normally when Application B is not used through an IFrame. Any suggestions how this could be solved? Or is the usage through an IFrame a bad idea from start? Any help is appreciated! Mahavishnu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Blog post on Wicket ...
I came across a reference to http://best-practice-software-engineering.blogspot.com/2007/08/tech-wicked-wicket.html this blog post last night and added a comment. I was surprised that I hadn't seen it before (it was originally posted in August). Regards - Cemal http://jWeekend.co.uk jWeekend.co.uk -- View this message in context: http://www.nabble.com/Blog-post-on-Wicket-...-tf4746040.html#a13571594 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
no i don't think Al lost, 1.4.2 or 1.4.3 that shouldn't matter But somewhere in your classpath you have and old version of 1 of the jars Please start the java process up with -verbose:gc and see what jar file it gives for org.slf4j.Logger johan On 11/4/07, landry soules [EMAIL PROTECTED] wrote: Sorry Al, but you lost your money ;-) I put back slf4j-api-1.4.2.jar , and still the same problem... Using the jars suggested by Cristi doesn't help either. But since it seems i'm the only one to still have the problem, must be a problem with my classpath. I will recheck after deploying the project in a war. Maybe it's just eclipse WTP that does some weird things with my classpath. As always, thanks a lot for your support, guys. 2007/11/3, Al Maw [EMAIL PROTECTED]: landry soules wrote: Actually, i didn't go on with maven, since my project is already quite advanced now, i don't want to reconfigure it to use maven. I just tried to create a sample project to figure out what is the correct combination of slf4j/log4j to use (bad idea, since it appears to be broken in the original wicket pom). So i'm back in my real eclipse project, and this neverending error : Exception in thread ModificationWatcher Task java.lang.NoSuchMethodError: org.slf4j.Logger.isTraceEnabled()Z at org.apache.wicket.util.thread.Task$1.run(Task.java:103) at java.lang.Thread.run(Thread.java:595) even though i'm using slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar. You also need slf4j-api-1.4.2.jar. I'd lay money on your not having that version on your classpath (or having an earlier version as well). Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
thats better. I think that throw exceptions on missing resources shouldn't happen in deployment mode anyway i think there is no much use for it a good log statement in the server log should be enough. i dont find it very dangerous that it shows the body IF it has a body because that you see it on your page you could see [THIS SHOULD BE A KEY] which is very easy to spot. But also the default text which is also fine. (except ofcourse if you think it comes from he db and you change something there and you don't see it, but then you change something or update something and then it should be able to look it up) johan On 11/4/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 11/3/07, Al Maw [EMAIL PROTECTED] wrote: Johan Compagner wrote: Yes we could do that. Just remove that default value. But what i would like to have IF you have a body specified then we don't throw anything This way we keep old behavior and we have the new one FWIW, I entirely agree with this. If we just change it for tags that have a default body then we'll almost certainly break people's sites. How about keeping this for the deployment mode (and log an error or warning once) but throw that exception in development mode? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just 1 hour to introduce Wicket (Friday)
I have had a lot of very positive feedback about the 1 hour Wicket
presentation I gave on Friday and I believe that team will now start
evaluating Wicket and are quite excited about it!
Members of 2 other teams asked if they could also attend but the turn-out
was already way beyond what anybody (including the project manager) had
expected, just from that one team, so there was standing room only in the
conference-room we had booked. I guess we may be asked for a repeat show
soon.
The posts on this thread and the http://manning.com/dashorst/ WIA reworked
chapter 1 Eelco sent me (not quite yet available publicly, I believe) were
very helpful. I also used a few slides from
http://cwiki.apache.org/WICKET/slides-and-presentations.html the wiki and
drew a few UML diagrams that made the Swing developers there feel at home.
So, thanks to everyone for all the helpful input and resources.
One hour is not long and flies quickly by during such presentations, so I
had only about 15 minutes at the end to show-off a bit of code and how easy
turning a link into an Ajax (and then Indicating Ajax) link is, mainly based
on Al's AjaxToggleButton demo from a recent Wicket Users event. The
attendees' seemed to be quite impressed by this (which we all probably just
take for granted now). Their questions (on state/scalability/clustering,
pretty urls, bookmarkable pages, security, Ajax, special tags ...) were
varied and very astute, IMO, considering some of them hadn't even heard of
Wicket before the presentation was arranged, and I think they were quite
impressed with Wicket.
Regards - Cemal
http://jWeekend.co.uk jWeekend.co.uk
PS Does the latest beta release (4) still work with the
http://wicket.apache.org/quickstart.html quickstart instructions. I saw
some posts suggesting that the pom is broken (slf4j and/or log4j versions)
and I'd like to warn them upfront so they don't get the wrong first
impressions, especially with something they can fix so easily if they know
what the problem is and that could waste so much time and cause unnecessary
frustration if they don't have any clue why it isn't just working (as I
told them things usually do in Wicket).
Eelco Hillenius wrote:
I like these points.
1. All code is Java, which enables end-to-end refactoring and gives
you clean html.
And static typing gives you also good means to navigate your code. Use
your
IDE to find the uses, overrides, etc. Make unsupported (due to API breaks)
methods final so that your clients break hard. Users of your components
can
use code completion and javadoc hoovers. All the good Java stuff.
2. Composition enables reuse. When I took a panel and moved it from a
tab on a page to a modalwindow on the page by changing a couple of
lines of code it made a big impact.
Another thing that is good about composition is that it makes it easier to
divide work. You don't have to work from page to page, but rather can pick
an course to very fine components.
3. Components have session state. Hence the content of the session is
determined by what components are on the page -- and further the
session is cleaned out as components leave scope. (And if state is
kept in url parameters then session is not used, in case anyone
complains about session size. State must be somewhere, no?)
In the new version of Wicket In Action's chapter one, I state this:
Wicket bridges the impedance mismatch between the stateless Hypertext
Transfer
Protocol (HTTP) and stateful Java programming. I added this after Dhanji
Prasanna asked me what I planned to say about that, which finally got that
light-bulb fired: 'that's indeed the core-core problem that Wicket tries
to
solve'.
Unfortunately, the new chapter wasn't included in the last MEAP download,
but I'm sending it to Cemal directly. I hope I do a better job than before
explaining the key points of Wicket.
Another (potential) interesting point is that Wicket is secure by default.
Here is an excerpt of chapter 12 (authentication and authorization):
With Wicket, if you don't code using bookmarkable pages, you use session
relative pages - Wicket's default way of coding web applications. Page
instances are kept on the server and you ask Wicket (through your browser)
for a certain page by providing the page number, version and the component
that is the target of the request. This works in the opposite way of the
REST architectural pattern, which states that servers should not keep
state,
but clients provide servers with the relevant state when they issue
requests. As we saw in the first chapter, REST is great for scalability,
but
lousy for the programming model. And now we get to another problem with
REST: the pattern is inherently unsafe, whereas Wicket's server state
pattern is safe by default.
For instance, if you implement the functionality of removing an object
using
a link like this:
final MyObject myObject = …
new Link(remove) {
Re: empty wicket:message
Johan Compagner wrote: thats better. I think that throw exceptions on missing resources shouldn't happen in deployment mode anyway i think there is no much use for it a good log statement in the server log should be enough. i dont find it very dangerous that it shows the body IF it has a body because that you see it on your page you could see [THIS SHOULD BE A KEY] which is very easy to spot. But also the default text which is also fine. (except ofcourse if you think it comes from he db and you change something there and you don't see it, but then you change something or update something and then it should be able to look it up) johan I definitely agree that in production mode it should not throw an exception for missing message resources. I don't like it if it shows the default body in development mode though. Either you have to type [THIS SHOULD BE A KEY] all the time, or you have to make an empty body, in both cases ruining your preview. If backwards compatiblity is necessary, why not just make it an option via the settings to turn off the exception throwing and revert to the body replacement? I would hate it if throwing the exceptions option is lost as soon as you fill in a body in the wicket:message tag... :-( Personally I think it would really help to have exceptions because they are hard to miss and scanning huge html pages for [MISSING KEY] is error prone too. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: wicket:enclosure and authorization
But we as the framework don't forget it ! If a developer overwrites isVisible() now then no mather what the developers returns if isRenderedAllowed() returns false then it won't be rendered. johan On 11/2/07, Igor Vaynberg [EMAIL PROTECTED] wrote: security is bypassed anyways because most component writers will forget to do the double check. so neither solution is good. -igor On 11/2/07, Johan Compagner [EMAIL PROTECTED] wrote: for visibility it is currently: isVisible()isRenderAllowed() which makes little sense to me because i have to deal with two concepts: visibility and rendering. from my point of view as a user i dont care to know about rendering, i just want to plop my components down and tweak their visibility. so just introduce an extra final method on component that does just that check. when we first introduced this i argued to make isenabled() and isvisible() include the is*allowed() checks, but i didnt win that one back then...but thats another thread. no i still think thats a bad idea, because then isEnabled and isVisible must be both final i guess because then with simple isVisible override by some developer the security is by passed. johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WICKET-606 Broken Again in beta4?
if this is still the case with RC1 can you make a testcase like eelco said so that we can have this covered. johan On 11/2/07, Dan Syrstad [EMAIL PROTECTED] wrote: It appears that the issue http://issues.apache.org/jira/browse/WICKET-606 that was fixed in beta2 is broken again in beta4. Basically TextFields for Strings (configured with the defaults) are always converting to empty strings. They should convert to null by default based on the AbstractTextComponent.getConvertEmptyInputStringToNull() setting, which is true by default. All of my TextFields are now setting empty strings on their Models where they used to set nulls. Can anyone confirm this? Do we need to reopen the issue? -Dan
Localizer cache
Hi, I was wondering if I could somehow turn off caching of the localizer in development mode (from the current source it doesn't look like it). The reason I ask is because now the cache is only flushed if a resource that is being watched is changed. However: * if you add a new properties file for a page or component after you already rendered the page once the cache is not cleared and it keeps finding the key=null entry in the cache. * if you add your own database string resource loader, the cache is never flushed at all. I know I can add a link to flush the localizer cache if and only if we're in development mode, but I think a Settings options could be nice to just turn off caching (my laptop is fast enough, I really don't care if it tries to resolve all the labels all the time). Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
OT: designer wanted - wicket look and feel
Hey everyone, I know this is off topic, but I'm looking for someone with graphic design experience for something with a very similar look and feel to the apache wicket website. If anyone knows who designed that site, or put together the wicketstuff wiki, or is just a good designer familar with that look and feel, I'd be very interested in talking with them for a small project. Feel free to contact me directly to discuss more. Thanks, Ryan http://ryan.codecrate.com
Re: WICKET-606 Broken Again in beta4?
I am trying, unsuccessfully, to reproduce it right now in a small test case. I will re-test with RC1 when it's available. -Dan On 11/4/07, Johan Compagner [EMAIL PROTECTED] wrote: if this is still the case with RC1 can you make a testcase like eelco said so that we can have this covered. johan On 11/2/07, Dan Syrstad [EMAIL PROTECTED] wrote: It appears that the issue http://issues.apache.org/jira/browse/WICKET-606 that was fixed in beta2 is broken again in beta4. Basically TextFields for Strings (configured with the defaults) are always converting to empty strings. They should convert to null by default based on the AbstractTextComponent.getConvertEmptyInputStringToNull() setting, which is true by default. All of my TextFields are now setting empty strings on their Models where they used to set nulls. Can anyone confirm this? Do we need to reopen the issue? -Dan
Re: wicket:enclosure and authorization
yes, but we encourage our users to write COMPONENTS. so if i want my component to do something different when it is not enabled i have to do isEnabled()==false||isEnabledAllowed()==false to check for when the component is disabled. and my point was that a lot of our users prob forget the isenabledallowed() check -igor On 11/4/07, Johan Compagner [EMAIL PROTECTED] wrote: But we as the framework don't forget it ! If a developer overwrites isVisible() now then no mather what the developers returns if isRenderedAllowed() returns false then it won't be rendered. johan On 11/2/07, Igor Vaynberg [EMAIL PROTECTED] wrote: security is bypassed anyways because most component writers will forget to do the double check. so neither solution is good. -igor On 11/2/07, Johan Compagner [EMAIL PROTECTED] wrote: for visibility it is currently: isVisible()isRenderAllowed() which makes little sense to me because i have to deal with two concepts: visibility and rendering. from my point of view as a user i dont care to know about rendering, i just want to plop my components down and tweak their visibility. so just introduce an extra final method on component that does just that check. when we first introduced this i argued to make isenabled() and isvisible() include the is*allowed() checks, but i didnt win that one back then...but thats another thread. no i still think thats a bad idea, because then isEnabled and isVisible must be both final i guess because then with simple isVisible override by some developer the security is by passed. johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem closing a ModalWindow when used through an IFrame
Hi! 2007/11/4, Matej Knopp [EMAIL PROTECTED]: Not yet, and I'm not sure I'm going to soon. Supporing modal window in iframe might be too big change for 1.3, because of they way modal window internally works. Ok. Btw. you example is broken, because you load page from wicket-library.com, which is different domain than where the iframe is. That will not work at all, since it would be cross-domain scripting, which browsers don't allow. We are studying if we could embed content from a wicket application (Site A) to another application (Site B) in different domain using an IFrame. Are you saying that we absolute should not try to do that? The IFrame opportunity is studied because Site B does not have a portal platform nor a WSRP support. And other reason is that the owner of Site B does not want to code any web UI code related to the application and there is a business need to have the new features of the wicket application available on Site B immediately when ever the application is updated. So this would make anykind of proxying or remote API based solutions difficult. There would be no need to communicate between the applications, just to visually embed the wicket application inside one page in site B. As far as we have tested the Closing of the ModalWindow is the only thing that has not worked in this setup. Everything else seems to work fine. We have tought that it would be considered as cross site scripting only if the Wicket Ajax components would try to refer to dom objects of site B. And we have no intention of doing so intentionally. Could that possibly be the reason why the ModalWindow does not close when used through an IFrame? Perhaps it tries to refer to the owner window by using HTMLdocument.parentor something like that? We could perhaps change the ModalWindow to something else that works in our case, and avoid that problem, but would you still say that we absolutely should not try this kind of setup although rest of the application seems to work through the IFrame? I would be very grateful to hear your opinions on this! DM -Matej On 11/4/07, Deepak Mahavishnu [EMAIL PROTECTED] wrote: Hi Matej! Have you been able to reproduce this problem? DM 2007/11/1, Deepak Mahavishnu [EMAIL PROTECTED]: Hi Matej! And thanks for a quick response! I opened a jira issue related to this. The quick start is very straight forward: Just create a html page with this source: html body iframe src= http://www.wicket-library.com/wicket-examples/ajax/modal-window.1; width=100% height=100%/iframe /body /html And then open Show modal dialog with panel and try to close the dialog. Mahavishnu 2007/11/1, Matej Knopp [EMAIL PROTECTED]: The modal window probably won't work well when paced in a page that is loaded in iframe. Still, if you can provide a quickstart assigned to a JIRA entry I will take a look if there is a quick fix for your problem. -Matej On 11/1/07, Deepak Mahavishnu [EMAIL PROTECTED] wrote: Hello! I'm doing some POC testing to find out how a wicket application could be used through an IFrame and noticed that closing of a ModalWindow fails. My setup: Application A: -a dummy html page that has an IFrame -the contents of the IFrame is requested from Application B iframe src=http://localhost:8080/mywicketapp/app/; width=100% height=500/iframe Application B: -a Wicket application that uses a ModalWindow -deployed to tomcat: http://localhost:8080/mywicketapp/ Problem: The ModalWindow is not closed when OK ( or Cancel ) button is clicked when Application B is used throug IFrame of Application A. OK button performs the actual action (in my case deletes an item from a list) but is not closed after the execution of the action. Closing of the ModalWindow works normally when Application B is not used through an IFrame. Any suggestions how this could be solved? Or is the usage through an IFrame a bad idea from start? Any help is appreciated! Mahavishnu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
Actually, it seems that the option class is useful in my case, not gc I couldn't find yet slf4j.Logger among the thousands lines generated(eclipse only retains the newer lines, erasing the olders), but i found something interesting : log4j.Logger is loaded from cayenne.jar... I'm quite puzzled : do i have to start spamming cayenne users list ? Or is this a bug (or at least a dangerous implementation) in beta4, that can cause problems not only with Cayenne, but also with some other frameworks ? Or maybe i can change the classpath load order in eclipse ? Thanks for your support. 2007/11/4, Johan Compagner [EMAIL PROTECTED]: no i don't think Al lost, 1.4.2 or 1.4.3 that shouldn't matter But somewhere in your classpath you have and old version of 1 of the jars Please start the java process up with -verbose:gc and see what jar file it gives for org.slf4j.Logger johan On 11/4/07, landry soules [EMAIL PROTECTED] wrote: Sorry Al, but you lost your money ;-) I put back slf4j-api-1.4.2.jar , and still the same problem... Using the jars suggested by Cristi doesn't help either. But since it seems i'm the only one to still have the problem, must be a problem with my classpath. I will recheck after deploying the project in a war. Maybe it's just eclipse WTP that does some weird things with my classpath. As always, thanks a lot for your support, guys. 2007/11/3, Al Maw [EMAIL PROTECTED]: landry soules wrote: Actually, i didn't go on with maven, since my project is already quite advanced now, i don't want to reconfigure it to use maven. I just tried to create a sample project to figure out what is the correct combination of slf4j/log4j to use (bad idea, since it appears to be broken in the original wicket pom). So i'm back in my real eclipse project, and this neverending error : Exception in thread ModificationWatcher Task java.lang.NoSuchMethodError: org.slf4j.Logger.isTraceEnabled()Z at org.apache.wicket.util.thread.Task$1.run(Task.java:103) at java.lang.Thread.run(Thread.java:595) even though i'm using slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar. You also need slf4j-api-1.4.2.jar. I'd lay money on your not having that version on your classpath (or having an earlier version as well). Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
On 11/4/07, landry soules [EMAIL PROTECTED] wrote: (eclipse only retains the newer lines, erasing the olders) Preferences - Run/Debug - Console - Limit console output Frank
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
landry soules wrote: Sorry Al, but you lost your money ;-) I put back slf4j-api-1.4.2.jar , and still the same problem... Using the jars suggested by Cristi doesn't help either. But since it seems i'm the only one to still have the problem, must be a problem with my classpath. I will recheck after deploying the project in a war. Maybe it's just eclipse WTP that does some weird things with my classpath. As always, thanks a lot for your support, guys. Gah. Can't believe you haven't sorted this issue out yet! It's conceptually really simple... org.slf4j.Logger#isTraceEnabled() ...is a method in the org.slf4j.Logger interface. That interface is in the main SLF4J API JAR. The isTraceEnabled() method, according to the javadoc, has been available in that interface since version 1.4. So you either don't have slf4j-api-1.4.x on your classpath, or you also have a version prior to 1.4 also your classpath which is being picked up instead. If both of those two things weren't the case, you wouldn't be having this issue. To check the classpath of a running project in Eclipse, Right click on the root node in the debug dialog and choose Properties. You can find the classpath in the dialog that is shown. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple wicket:child / tags on a single base page?
The only requirement would be that if you do choose to support multiple
abstract/overridden sections you would need to provide identifiers (just
like an abstract method has a name) so that the 'compiler' (wicket)
knows which section in a superclass an extended class section is
overriding. In pages where only one section is overridden no identifiers
would be necessary and so existing markup works without change, the way
it does now.
isn't this section exactly what igor said in his post?
make 1 page
that has 2 identifiers (that are 2 divs like
div wicket:id=method1/div
div wicket:id=method2/div
and the class had
abstract class MyBasePage
{
MyBasePage()
{
add(method1());
add(method2());
}
abstract Panel method1()
abstract Panel method2()
}
as far as i know you have pretty much exactly what you describe.
johan
Re: Localizer cache
Best to open a proper feature request for this in JIRA. Eelco On 11/4/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Hi, I was wondering if I could somehow turn off caching of the localizer in development mode (from the current source it doesn't look like it). The reason I ask is because now the cache is only flushed if a resource that is being watched is changed. However: * if you add a new properties file for a page or component after you already rendered the page once the cache is not cleared and it keeps finding the key=null entry in the cache. * if you add your own database string resource loader, the cache is never flushed at all. I know I can add a link to flush the localizer cache if and only if we're in development mode, but I think a Settings options could be nice to just turn off caching (my laptop is fast enough, I really don't care if it tries to resolve all the labels all the time). Regards, Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to Jquery, Json, wicket spring?
We are developing a new web based application in wicket, we need to integrate Ajax(Jquery 1.2) with JSON data format and wicket(1.3). Does anybody know how to do this? any sample example or pointer will be great full. I have googled and could not find anything. Also is there any example to integrate Wicket(1.3) with spring using new spring annotations 2.5? thanks Pen -- View this message in context: http://www.nabble.com/How-to-Jquery%2C-Json%2C-wicket-spring--tf4749547.html#a13581144 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Spring Authenticated Web Application
Hi All, I am currently working on a project which uses Wicket as view layer and Spring as service layer, therefore my web application class extends Spring Web Application. I want to integrate Acegi in order to handle the security issues. I came across this article http://cwiki.apache.org/WICKET/acegi-and-wicket-auth-roles.html that explains the integration between wicket and acegi. However it mentions that I need to extend AuthenticatedWebApplication. So, what should I do in this case? is there any other class the I can extend that combine both Spring and Acegi? is there any other way to integrate Acegi? Regards, Suad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to Jquery, Json, wicket spring?
Hi, I started the wicketstuff-jquery project, currently there is no doc/wiki, only the [source][1] is available and a demo application ([source][2], [war][3]). For the communication with between client and server, I used the native Wicket API, simpler than trying to write it in JSON (client and server). every feedbacks, helps,... are welcome through this mailing list (please prefix subject with [wicketstuff-jquery] or via the issue tracker) [4]. [1]: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-jquery/ [2]: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-jquery-examples/ [3]: http://alchim.sourceforge.net/download/wicketstuff-jquery-examples-0.1-SNAPSHOT.war [4]: http://wicketstuff.org/jira/browse/WSJQUERY Pen wrote: We are developing a new web based application in wicket, we need to integrate Ajax(Jquery 1.2) with JSON data format and wicket(1.3). Does anybody know how to do this? any sample example or pointer will be great full. I have googled and could not find anything. Also is there any example to integrate Wicket(1.3) with spring using new spring annotations 2.5? thanks Pen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring Authenticated Web Application
see spring wiki page. your webapp subclass does not need to extend springwebapp in order to use spring. -igor On 11/4/07, Suad AlShamsi [EMAIL PROTECTED] wrote: Hi All, I am currently working on a project which uses Wicket as view layer and Spring as service layer, therefore my web application class extends Spring Web Application. I want to integrate Acegi in order to handle the security issues. I came across this article http://cwiki.apache.org/WICKET/acegi-and-wicket-auth-roles.html that explains the integration between wicket and acegi. However it mentions that I need to extend AuthenticatedWebApplication. So, what should I do in this case? is there any other class the I can extend that combine both Spring and Acegi? is there any other way to integrate Acegi? Regards, Suad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
