Re: Question about localization
Yes, I'll make it part of the key. I searched but not found, how can I change the default localizer and the default resourcemodel? There is no method "setLocalizer"/"setResourceModel" in class WebApplication... Thank you for your help. igor.vaynberg wrote: > > you can override methods in localizer to bend it to your will, but > like i said beware if you do not expect to make style part of the key > > -igor > -- View this message in context: http://www.nabble.com/Question-about-localization-tf4756837.html#a13623105 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: Multiple tags on a single base page?
Well, the tags are not new, as they do the perfectly same as extend and child. Basically, the patch only introduces an id attribute to those tags in order to make linking of markup more flexible. The new names were only introduced to keep functionality of the patch separated from the existing (and as the names child/extend are not very well chosen, as they aren't naturally related) I see that it was a bad idea to rename the tags for the prototype. Obviously, everybody fears new tags and therefore dismisses the whole idea only for that reason. Evan Chooly wrote: > > In our app we have a ListView into which we can dump panels for, in > our case, various different filtering options depending on the page. > The base page keeps a List and that's used as the model for the > ListView. If the subclass doesn't add anything, nothing shows up. > But the pages that need them can add them. These panels show up in > the base page's markup area (outside the area) with no > hackery needed. > > I think the proposed patch is an overly complicated solution to > "problem" that has many different simple solutions. I agree with the > earlier comments about the proliferation of tags in wicket. I'd > rather not see new tags added just for this. It fuglifies the markup > for no real gain. > > On Nov 6, 2007 11:30 AM, Stefan Fußenegger <[EMAIL PROTECTED]> > wrote: >> >> I posted a new message in Wicket - Dev: >> http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html >> >> It contains a patch that demonstrates the discussed enhancement. Please >> comment! >> >> -- stefan >> >> >> Stefan Fußenegger wrote: >> > >> > Hi folks, >> > >> > I just stumbled on a situation where it would be useful to have two or >> > more tags in a base page. Just consider a layout that >> > consists of the usual footer, header, navigation, and content parts. >> But >> > now, the content should be arranged in two columns, e.g. two different >> > s. >> > >> > To give a short example, the BasePage.html cloud look like this >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > And the Child.html markup would look like this: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Wouldn't that be a desirable feature? I tried to run the above example >> > expecting to get an exception. The second wicket:child/wicket:extend >> pair >> > was happily ignored though. >> > >> > Best regards, Stefan >> > >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287 >> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> 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] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623106 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: Multiple tags on a single base page?
Hey Chris, I would need some lobbying here! ;)
-- stefan
Chris Colman wrote:
>
>> Wouldn't this essentially be the same as using > id="header"/> and using WebMarkupContainers on the java side?
>> I.e.:
>>
>> Base
>>
>
> Structural markup goes here (see below for explanation of this)
>
>>
>
> More structural markup goes here
>
>>
>
> And again more structural markup goes here too
>
>>
>> PumpsBase
>> -
>>
>> A header for all pages to do with pumps
>>
>>
>> Note: no body implemented here - deferred until a more specialized
>> class/markups: WaterPumpsBase and OilPumpsBase
>>
>> WaterPumpBase
>> -
>> Note: no header implemented here - the general PumpsBase one suffices
>> for all pumps pages
>>
>>
>> A body discussing water pumps
>>
>>
> ...
>
>>
>> On the java side you'd have to addOrReplace(new
>> WebMarkupContainer("header")) but it's essentially the same. Or am I
>> missing some point?
>
> This is indeed very different. If it were not so then the wicket
> developers would never have conceived the need for the current
> child/extend tag pair.
>
> The power of inheritance at the markup level is that you can define
> markup once in a base markup file that is inherited by all derived
> markup files. The derived markup files only supply sections that provide
> "specialized sections of markup - the rest, at render time, comes from
> the base class.
>
> You would typically use components (panels) within these specialized
> sections but using the panel mechanism as you describe above as a
> replacement for the powerful markup inheritance feature of wicket is not
> possible.
>
> In the panel example you give you must still provide all of the
> structural markup surrounding your panel tags in EVERY page's markup in
> your system and if you decide to make a system wide change of this
> structural markup you must edit every page's markup to reflect that
> change. In an OO markup world you provide the structural markup in as
> many pages as you want but at render time the only structural markup
> used is that provided in the base base - which is very powerful because
> you can make system wide changes by modifying only that single base
> page's markup. Wicket is the first framework I've seen that allows
> proper OO reuse concepts at the markup level.
>
> This is what many people wicket developers with an OO wiring in their
> brain are doing right now with the existing child/extend feature - and
> to great benefit.
>
> This new feature, or extension of the exiting feature, allows more than
> one section of markup to be "specialized" by derived (extended) markups
> whereas currently wicket only supports the deferred
> definition/implementation of a single markup section in any page. In
> other words we want to make a powerful feature even more powerful.
>
> It must be stated again (for the benefit of those who have just recently
> joined this thread) that supporting multiple sections whose
> implementation can be deferred to extended markups does not equate to
> multiple inheritance (a big "no no" in the OO world). Multiple
> overridden sections is analogous to the support of multiple abstract
> methods whose implementations are provided in classes that extend the
> base class - which is supported in all good OO languages, including
> Java.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623108
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: Problem with wicket authentication
Hugues Pichereau wrote:
Sebastiaan van Erk wrote:
[...]
If you do override init, make sure to call super.init()
Whao! well done, Sebastiaan, I was overriding init(), and not calling
super.init();
Now it works.
But what bugs me is that it solves my own application (where init() was
overrided), but not the modified Wicket QuickStart application (where init()
was NOT overrided) :confused:
Use the same method with breakpoints to check that init() of the
AuthenticatedWebApplication is hit. My bet is that you have the wrong
application class in your web.xml.
Regards,
Sebastiaan
Regards,
Hugues
Sebastiaan van Erk wrote:
[pasted from a private email]
Do you have the wicket source attached?
Because the best thing to do is just to step through the process.
First place to start is to see if init() method is called in
AuthenticatedWebApplication. (In your code below you do not override
init, so it should be called. If you do override init, make sure to call
super.init()).
If the init method is called, put a breakpoint in the
AnnotationsRoleAuthorizationStrategy on the isInstantiationAuthorized
method and see if that gets hit.
Regards,
Sebastiaan
Sebastiaan van Erk wrote:
Looks good to me.
I'm using just like you are. Are you sure that your wicket application
class is correct (i.e., that your filter is actually using
WicketApplication, and not WebApplication or something like that)?
I sugguest putting some breakpoints and checking the logs. Your
getHomePageClass() should be called for example, so putting a breakpoint
there will tell you if your starting the correct application. Or a
breakpoint in getWebSessionClass() will tell you if the authentication
is being initalized etc...
Regards,
Sebastiaan
Hugues Pichereau wrote:
Hi,
I would like to use Wicket authentication, as in the examples.
So I modified the Wicket QuickStart project to use authentication, like
this:
public class WicketApplication extends AuthenticatedWebApplication {
public WicketApplication() {
}
public Class getHomePage() {
return HomePage.class;
}
@Override
protected Class getSignInPageClass() {
return LoginPage.class;
}
@Override
protected Class
getWebSessionClass() {
return WicketSession.class;
}
}
public class WicketSession extends AuthenticatedWebSession {
public WicketSession(AuthenticatedWebApplication application, Request
request) {
super(application, request);
}
@Override
public boolean authenticate(String arg0, String arg1) {
return false; // should block everybody
}
@Override
public Roles getRoles() {
return null;
}
}
HomePage.html has:
# Admin page
public class HomePage extends WebPage {
public HomePage(final PageParameters parameters) {
add(new PageLink("goto-admin", AdminPage.class));
}
}
LoginPage.html has:
public final class LoginPage extends SignInPage {
}
And finally, the admin page to protect:
@AuthorizeInstantiation("USER")
public class AdminPage extends WebPage {
}
The problem is that a click from the HomePage always brings the
AdminPage, without any
LoginPage displayed.
I used Wicket 1.3 beta4.
After reading the Wicket example and 2 tutorials on authentication, I
really can't see what I'm missing.
Any idea ?
Hugues
smime.p7s
Description: S/MIME Cryptographic Signature
Re: multiple url mappings for the wicket web application
Johan Compagner wrote: I dont think that will work quite that way out of the box. because our normal statefull redirect page will go to /?wicket:interface=:0: And also form post will go to that kind of url (and then redirect) Actually, we rely on the servlet container to convert relative URL redirects into absolute ones for us. It does this by looking at the request URL, so I think this might work just fine. I'm assuming here that Tom is using web.xml to set up the NL/*, EN/* etc. mappings. You're assuming the mappings are done using a single page entry-point, which isn't what he means, I think. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help understaning AjaxCallDecorator problem
skatz wrote: Is it possible for a javascript function to fail in such a way that the rest of the script would not be called? It can throw an exception. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with wicket authentication
Swarm is designed to be plain and simple.
In short this is what you need to do:
1 implement Principal (i could see about a reasonable default
implementation , but my guess is you want to store this in a database
anyway and i am not sure i want a dependency on jpa)
2 create policy files
3 implement WaspApplication (by extending SwarmApplication)
Off the top of my hat, that is al you need to get the default running.
Off course if you want something special you need something more, but
where don't you need to do that.
But if you feel we could improve on some areas, let me know.
Maurice
On Nov 6, 2007 10:35 PM, <[EMAIL PROTECTED]> wrote:
> I wished to try the basic Wicket authentication because it looked plain
> simple (and simplicity and fewer code is my mantra!)
> I had seen the Swarm one, but it didn't look as straightforward. Maybe I will
> give it a try if I can't go with the standard one.
>
> Regards,
> Hugues
>
> Mr Mean wrote:
> >
> > You are using the wrong authorization framework!
> >
> > :) No seriously now. I don't know what is wrong with your code,
> > although the authenticate method might give some useful debugging
> > info.
> > There is however a second authorization framework for wicket called
> > Swarm. you might want to check it out.
> > http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security
> >
> > Maurice
> >
> > P.S. warning: shameless self-promoting :)
> >
> >
>
> > On Nov 5, 2007 2:32 PM, Hugues Pichereau <[EMAIL PROTECTED]> wrote:
> >> Hi,
> >>
> >> I would like to use Wicket authentication, as in the examples.
> >> So I modified the Wicket QuickStart project to use authentication, like
> >> this:
> >>
> >> public class WicketApplication extends AuthenticatedWebApplication {
> >>
> >>public WicketApplication() {
> >>}
> >>
> >>public Class getHomePage() {
> >> return HomePage.class;
> >>}
> >>
> >>@Override
> >>protected Class getSignInPageClass() {
> >> return LoginPage.class;
> >>}
> >>
> >>@Override
> >>protected Class
> >> getWebSessionClass() {
> >> return WicketSession.class;
> >>}
> >> }
> >>
> >>
> >> public class WicketSession extends AuthenticatedWebSession {
> >>
> >>public WicketSession(AuthenticatedWebApplication application, Request
> >> request) {
> >> super(application, request);
> >>}
> >>
> >>@Override
> >>public boolean authenticate(String arg0, String arg1) {
> >> return false; // should block everybody
> >>}
> >>
> >>@Override
> >>public Roles getRoles() {
> >> return null;
> >>}
> >> }
> >>
> >>
> >> HomePage.html has:
> >> # Admin page
> >>
> >> public class HomePage extends WebPage {
> >>
> >>public HomePage(final PageParameters parameters) {
> >> add(new PageLink("goto-admin", AdminPage.class));
> >>}
> >> }
> >>
> >>
> >> LoginPage.html has:
> >>
> >>
> >> public final class LoginPage extends SignInPage {
> >> }
> >>
> >>
> >> And finally, the admin page to protect:
> >>
> >> @AuthorizeInstantiation("USER")
> >> public class AdminPage extends WebPage {
> >> }
> >>
> >> The problem is that a click from the HomePage always brings the
> >> AdminPage, without any
> >> LoginPage displayed.
> >>
> >> I used Wicket 1.3 beta4.
> >>
> >> After reading the Wicket example and 2 tutorials on authentication, I
> >> really can't see what I'm missing.
> >> Any idea ?
> >>
> >> Hugues
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> Quoted from:
> http://www.nabble.com/Problem-with-wicket-authentication-tf4751663.html#a13602300
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Possible to use wicket to serve non-HTML content?
Hi, for my current project I had to serve some PDF files. I am using Velocity to some of my HTML content as printable, and this is done as plain Velocity code, and then have a Wicket page serve that content (by simply having a plain page with [content] and setting the renderBodyOnly as true). I need to serve PDF next, which I would use the same way to generate my HTML, integrate with a HTML->PDF library (might be looking into iText), done on the fly. The flow is as this for the end user 1. User reach a page of document (Wicket) 2. User is presented two options, view as Printable, or download as PDF 3. User clicked on view as Printable, and the above mentioned velocity generated HTML is embedded into the Wicket page, and then served to the user 4. User clicked on download as PDF, and should reach a page where he can download a PDF version of the document, generated on the fly. I could do this with a servlet or filter, but I was wondering if there is a Wicket way to have a page serve non-html content, as most of my 'business service objects' are currently in Wicket, injected with Spring. And if I do so with a servlet/filter, does a WebApplication.get() allow me to gain access to the same spring context from the servlet? This is essential for me now because my current data storage are all in memory, which are singletons from the spring context (this allows me to do rapid prototyping, testing and development without worrying about the storage implementation at this stage) Thanks for any advices. Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] CSS issues - suggestions?
Gwyn Evans wrote: I've got some text that shows up fine in Firefox but only when selected in IE (IE7) and I've no idea what the real issue is, so I'm hoping someone can take a glance. That bug tends to be triggered by floats, but there are various things that can cause it. You can almost always work around it by giving the affected element "layout". See: http://www.satzansatz.de/cssd/onhavinglayout.html You could also try making the element position: relative and see if that fixes it. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
ok tell me with 2 examples what is soo different about having 2 panels (or fragments) in a page and implement that in a sub page or having 2 wicket childs in a page and implement those in a sub page. A basepage can also have ofcourse an extend area and 2 panels.. johan On 11/7/07, Chris Colman <[EMAIL PROTECTED]> wrote: > > > > Wouldn't this essentially be the same as using > > id="header"/> and using WebMarkupContainers on the java side? > > > > > > yes it would be exactly the same thing. > > If you think that these are the same then you've missed some vital plot > points of the movie that it child/extend. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: Multiple tags on a single base page?
> > Wouldn't this essentially be the same as using > id="header"/> and using WebMarkupContainers on the java side? > > > yes it would be exactly the same thing. If you think that these are the same then you've missed some vital plot points of the movie that it child/extend. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] CSS issues - suggestions?
Hi Al, On 07 November 2007, 9:42:36 AM, Gwyn Evans wrote: AM> Gwyn Evans wrote: >> I've got some text that shows up fine in Firefox but only when >> selected in IE (IE7) and I've no idea what the real issue is, so I'm >> hoping someone can take a glance. AM> That bug tends to be triggered by floats, but there are various things AM> that can cause it. You can almost always work around it by giving the AM> affected element "layout". AM> See: http://www.satzansatz.de/cssd/onhavinglayout.html AM> You could also try making the element position: relative and see if that AM> fixes it. Thanks - still to go through the doc, but at first glance, it looks very promising. I've managed to get it down to this (wonder if it'll come through!) Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Sed condimentum consequat urna. Lorem so should be able to test it easy enough. -- /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Link text
Anything similar for spitting something out _after_ the tag that the
component is mapped to? e.g. Sending out some text/html after a checkbox?
Presumably onComponentTagBody doesn't get called because it is not a
Container and the input tag is send after anything I do in onComponentTag :(
Al Maw wrote:
>
> Sam Hough wrote:
>> Lots of the time I just want a link with text as the body of the ... ...
>>
>> The Link class takes an IModel so presumably uses that for something but
>> I
>> can't see it in the source or get it to appear...
>>
>> Sorry I'm being thick and I did search honest!
>
> You'd typically use the model so you have something to get at in the
> onClick().
>
> Of course, if you don't care about how much state is in your session,
> you can just make whatever it is final so you can use it in there anyway.
>
> If you want to use the model for the text of the link instead, then you
> could write a class like this:
>
>
> public abstract class TextLink extends Link {
> public TextLink(String id, IModel model) {
> super(id, model);
> }
>
> protected void onComponentTagBody(final MarkupStream markupStream,
> final ComponentTag openTag)
> {
> replaceComponentTagBody(
> markupStream, openTag, getModelObjectAsString()
> );
> }
>
> }
>
>
> If you want enabled/disabled to work properly, you'll need to copy the
> relevant bits out of AbstractLink#onComponentTagBody(...)
>
>
> Regards,
>
> Al
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Link-text-tf4751114.html#a13624806
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: Multiple tags on a single base page?
On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
> Hmm...I'm interested in seeing the difference as well. I would love to
> get it but right now I don't.
>
> Chris Colman wrote:
> "This new feature, or extension of the exiting feature, allows more than
> one section of markup to be "specialized" by derived (extended) markups
> whereas currently wicket only supports the deferred
> definition/implementation of a single markup section in any page. In
> other words we want to make a powerful feature even more powerful."
>
> Is the above statement really true considering that by adding abstract
> methods to your page you defer the creation of the markup in just the
> same way as the new proposed solution?
>
> BasePage.java
>
> public BasePage() {
> addAbstract1("abstractId1");
> addAbstract2("abstractId2);
> }
>
> public abstract addAbstract1(String abstractId1);
> public abstract addAbstract2(String abstractId2);
A little typo here..I meant:
public BasePage() {
add(addAbstract1("abstractId1"));
add(addAbstract2("abstractId2));
}
public abstract Component addAbstract1(String abstractId1);
public abstract Component addAbstract2(String abstractId2);
/Mats
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Hmm...I'm interested in seeing the difference as well. I would love to
get it but right now I don't.
Chris Colman wrote:
"This new feature, or extension of the exiting feature, allows more than
one section of markup to be "specialized" by derived (extended) markups
whereas currently wicket only supports the deferred
definition/implementation of a single markup section in any page. In
other words we want to make a powerful feature even more powerful."
Is the above statement really true considering that by adding abstract
methods to your page you defer the creation of the markup in just the
same way as the new proposed solution?
BasePage.java
public BasePage() {
addAbstract1("abstractId1");
addAbstract2("abstractId2);
}
public abstract addAbstract1(String abstractId1);
public abstract addAbstract2(String abstractId2);
BasePage.html
What is the difference between that and doing abstract / implements?
Each page inheriting from BasePage can choose to be as abstract or as
concrete as it wants.
Chris, I feel like I'm missing something vital herecan you try to
explain it just one more time?
/Regards Mats
On Nov 7, 2007 11:11 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> ok tell me with 2 examples what is soo different about having 2 panels (or
> fragments)
> in a page and implement that in a sub page or having 2 wicket childs in a
> page
> and implement those in a sub page.
>
> A basepage can also have ofcourse an extend area and 2 panels..
>
> johan
>
>
>
>
> On 11/7/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> >
> > > > Wouldn't this essentially be the same as using > > > id="header"/> and using WebMarkupContainers on the java side?
> > >
> > >
> > > yes it would be exactly the same thing.
> >
> > If you think that these are the same then you've missed some vital plot
> > points of the movie that it child/extend.
> >
> > -
> > 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: Link text
Doh. Should have thought of Behaviours (sic). Guess my coding style is a bit old fashioned trying to use extension from than composition. Must re-read that great article about the pattern behind Spring not intending things to be extended. Cheers Sam Al Maw wrote: > > Sam Hough wrote: >> Anything similar for spitting something out _after_ the tag that the >> component is mapped to? e.g. Sending out some text/html after a checkbox? >> >> Presumably onComponentTagBody doesn't get called because it is not a >> Container and the input tag is send after anything I do in onComponentTag >> :( > > Have a look at how WicketAjaxIndicatorAppender works. > > Regards, > > Al > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Link-text-tf4751114.html#a13624978 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: gmap2 and map creation
I'm pretty sure I'm using the latest version: $ svn info Path: . URL: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-gmap2 Repository Root: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff Repository UUID: ef7698a4-5110-0410-9fc6-c7eb3693863f Revision: 3219 Node Kind: directory Schedule: normal Last Changed Author: funkattack Last Changed Rev: 3149 Last Changed Date: 2007-10-23 21:44:10 +0100 (Tue, 23 Oct 2007) Actually, that stack trace might have been misleading as I had been playing around with the code in GMap2... Here's a stack trace with the original version: Caused by: org.apache.wicket.WicketRuntimeException: This component is not (yet) coupled to a page. It has to be able to find the page it is supposed to operate in before you can call this method (Component#getMarkupId) at org.apache.wicket.Component.getMarkupId(Component.java:1201) at wicket.contrib.gmap.GMap2.getJSinvoke(GMap2.java:399) at wicket.contrib.gmap.GMap2.getJSsetCenter(GMap2.java:424) at wicket.contrib.gmap.GMap2.setCenter(GMap2.java:353) Jan On 06/11/2007, Martin Funk <[EMAIL PROTECTED]> wrote: > > Hi Jan, > > > to operate in before you can call this method (Component#getMarkupId) > > at org.apache.wicket.Component.getMarkupId(Component.java:1201) > > at wicket.contrib.gmap.GMap2.getJSinvoke(GMap2.java:399) > > at wicket.contrib.gmap.GMap2.getJSsetZoom(GMap2.java:424) > > at wicket.contrib.gmap.GMap2.setZoom(GMap2.java:353) > > > > > > (This is with Wicket 1.3 beta 4, and the head of gmap2) > > > > Looking at the line numbers I'd ask, are you sure you are running the > latest wicket-contrib-gmap2? > > like > > svn info > Pfad: . > URL: > > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-gmap2 > Basis des Projektarchivs: > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff > UUID des Projektarchivs: ef7698a4-5110-0410-9fc6-c7eb3693863f > Revision: 3219 > Knotentyp: Verzeichnis > Plan: normal > Letzter Autor: funkattack > Letzte geänderte Rev: 3149 > Letztes Änderungsdatum: 2007-10-23 22:44:10 +0200 (Di, 23 Okt 2007) > > Also the description sounds like something we might have covered in the > one of the last updates. > > Have fun, > > Martin > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Link text
Sam Hough wrote: Anything similar for spitting something out _after_ the tag that the component is mapped to? e.g. Sending out some text/html after a checkbox? Presumably onComponentTagBody doesn't get called because it is not a Container and the input tag is send after anything I do in onComponentTag :( Have a look at how WicketAjaxIndicatorAppender works. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Popup parent comunication
Hello! I have the following problem. I have a parent page, that opens a popup through a PageLink. The popup window is a window in which new records can be added, but i need a combo in the parent page to reflect and contain also the new choice added in the popup. 1. Reloading the whole parent page at popup close link pressed i would take as the last resolve because the user may have introduced data in the controls that would get lost in the reloading process. I could get around this by adding a submit behaviour to the link and save in session the values inserted till that moment and rehidrate the model with values from the session instead of the database, and so obtain the state that the page was in before the popup was opened, but i'm wondering if there is not a cleaner solution for this. 2. I also tried(didn't think this would work:) but had to try) to pass the combo to the popup page and tried to update through the pressing of an ajaxlink the combo. It said it could not find the markup id for the combo(expected since it tried in the popup and not in the parent) so i guess that this approach could be made valid if the ajax callback would be directed at the parent page instead of the popup - i do not know how to do this. 3. Another option I am considering is calling a self.opener.function in which i would have javascript code for the ajax update of the combo in the parent. What code that is doing the ajax update i still do not know where to find-> maybe on the onselectionchange behaviour would be the way to find out, or if it breaks something in the way wicket is working. Anybody has any pointers of what would be the nice way to implement, comments, or other ways to tackle the problem? Thanks. -- View this message in context: http://www.nabble.com/Popup-parent-comunication-tf4763947.html#a13625027 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: Multiple tags on a single base page?
> Hmmm... more tags? I thought you guys liked Wicket because it's plain html > support. Now looks like there's a big interest in having more tags. If > this is true, why don't we go back a few years, or move to JSF? Let's give > Wicket support to Tag Libraries too :) > These aren't just like other tags - not having these is like removing the abstract keyword from the Java language. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> Hey Chris, I would need some lobbying here! ;)
>
> -- stefan
You're doing a great job Stefan - especially now I see that you've implemented
it - excellent job!
Are we both seeing something here that other people can't see? It wouldn't be
the first time in my life I was in that position - only years later do people
go "oh yeah" what a great idea...
I can only guess that most people haven't actually discovered the power and
reuse facilitated by the child/extend tag because if they had then it's not
such a great stretch to see the power of supporting more than one extendible
section - we're just arguing over multiplicity, not the extendible section
concept itself.
Most of the "panels can do that" arguments, in my mind, disparage the existing
child/extend concept as much as they do the proposed support for multiple
single extendible sections.
The, "I can do that with panels" argument sounds like C programmers back in the
early 90s saying, "I don't need C++ I can do everything in C with function
pointers". Well you probably could but by embarking on a short learning curve
you could be 1000x times more productive.
Someone asked for another explanation of the difference so I'll do that again
in a following post.
>
>
>
> Chris Colman wrote:
> >
> >> Wouldn't this essentially be the same as using >> id="header"/> and using WebMarkupContainers on the java side?
> >> I.e.:
> >>
> >> Base
> >>
> >
> > Structural markup goes here (see below for explanation of this)
> >
> >>
> >
> > More structural markup goes here
> >
> >>
> >
> > And again more structural markup goes here too
> >
> >>
> >> PumpsBase
> >> -
> >>
> >> A header for all pages to do with pumps
> >>
> >>
> >> Note: no body implemented here - deferred until a more specialized
> >> class/markups: WaterPumpsBase and OilPumpsBase
> >>
> >> WaterPumpBase
> >> -
> >> Note: no header implemented here - the general PumpsBase one suffices
> >> for all pumps pages
> >>
> >>
> >> A body discussing water pumps
> >>
> >>
> > ...
> >
> >>
> >> On the java side you'd have to addOrReplace(new
> >> WebMarkupContainer("header")) but it's essentially the same. Or am I
> >> missing some point?
> >
> > This is indeed very different. If it were not so then the wicket
> > developers would never have conceived the need for the current
> > child/extend tag pair.
> >
> > The power of inheritance at the markup level is that you can define
> > markup once in a base markup file that is inherited by all derived
> > markup files. The derived markup files only supply sections that provide
> > "specialized sections of markup - the rest, at render time, comes from
> > the base class.
> >
> > You would typically use components (panels) within these specialized
> > sections but using the panel mechanism as you describe above as a
> > replacement for the powerful markup inheritance feature of wicket is not
> > possible.
> >
> > In the panel example you give you must still provide all of the
> > structural markup surrounding your panel tags in EVERY page's markup in
> > your system and if you decide to make a system wide change of this
> > structural markup you must edit every page's markup to reflect that
> > change. In an OO markup world you provide the structural markup in as
> > many pages as you want but at render time the only structural markup
> > used is that provided in the base base - which is very powerful because
> > you can make system wide changes by modifying only that single base
> > page's markup. Wicket is the first framework I've seen that allows
> > proper OO reuse concepts at the markup level.
> >
> > This is what many people wicket developers with an OO wiring in their
> > brain are doing right now with the existing child/extend feature - and
> > to great benefit.
> >
> > This new feature, or extension of the exiting feature, allows more than
> > one section of markup to be "specialized" by derived (extended) markups
> > whereas currently wicket only supports the deferred
> > definition/implementation of a single markup section in any page. In
> > other words we want to make a powerful feature even more powerful.
> >
> > It must be stated again (for the benefit of those who have just recently
> > joined this thread) that supporting multiple sections whose
> > implementation can be deferred to extended markups does not equate to
> > multiple inheritance (a big "no no" in the OO world). Multiple
> > overridden sections is analogous to the support of multiple abstract
> > methods whose implementations are provided in classes that extend the
> > base class - which is supported in all good OO languages, including
> > Java.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> -
> ---
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer do
Re: Multiple tags on a single base page?
Hi Mats, let me try to explain what Chris and I see here that others don't -
may it be there or not ;)
You can of course do everything with panels that could be done with multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you wouldn't need markup inheritance
at all! The proposed change is just an extension of exactly this markup
inheritance concept (that everybody loves) to make it even more powerful
than it already is.
I was quite new to wicket (which I still am) and came across a situation
where I wanted to use two abstract sections: one for a sub-navigation that
was common for several pages in a section and one for the actual content.
For me, as a wicket newbie, it would have been most natural to use markup
inheritance to solve this problem. Using abstract methods, while being a
nice solution (workaround?), didn't come to my mind at once, nor did I find
it somewhere in the docs.
imho, there are two possible solution to this problem:
1. promote using abstract methods for this in the docs as the wicket-way of
doing it
2. extend the current markup inheritance mechanism (which I tried to do with
my patch/prototype)
-- stefan
Mats Norén-2 wrote:
>
> On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
>> Hmm...I'm interested in seeing the difference as well. I would love to
>> get it but right now I don't.
>>
>> Chris Colman wrote:
>> "This new feature, or extension of the exiting feature, allows more than
>> one section of markup to be "specialized" by derived (extended) markups
>> whereas currently wicket only supports the deferred
>> definition/implementation of a single markup section in any page. In
>> other words we want to make a powerful feature even more powerful."
>>
>> Is the above statement really true considering that by adding abstract
>> methods to your page you defer the creation of the markup in just the
>> same way as the new proposed solution?
>>
>> BasePage.java
>>
>> public BasePage() {
>> addAbstract1("abstractId1");
>> addAbstract2("abstractId2);
>> }
>>
>> public abstract addAbstract1(String abstractId1);
>> public abstract addAbstract2(String abstractId2);
>
> A little typo here..I meant:
>
> public BasePage() {
> add(addAbstract1("abstractId1"));
> add(addAbstract2("abstractId2));
> }
>
> public abstract Component addAbstract1(String abstractId1);
> public abstract Component addAbstract2(String abstractId2);
>
> /Mats
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
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: gmap2 and permissions
Hi Martin, adding the header contributions in the way suggested works fine for me, and I think this is an acceptable workaround for now. Many thanks for your quick response! Regards, Jan On 06/11/2007, Martin Funk <[EMAIL PROTECTED]> wrote: > > Hi Jan, > > the good news is that I think we got a better understanding on this > question, the bad news is we only can offer a workaround, not an elegant > solution. > > The problem is that Firefox and obviously Konqueror too object to load > external
Re: eHour migrated to Wicket
> I've finally migrated my time tracking tool, eHour, from Struts to Wicket ! > > eHour is a webbased time tracking tool for consultancy companies and > other project based businesses. > The primary objective is to keep time tracking as simple and user > friendly as possible while still being > very effective at measuring and reporting the amount of time your team > spends on a project. > More details at http://www.ehour.nl/ Congrats! Looks good. > I have to say that I underestimated the amount of time needed to do the > whole migration, mostly due to the amount > of JSP/JSTL/Struts code I had to migrate and the learning > curve/documentation of Wicket. But I'm still very happy I > did the migration. Development is fun again and Wicket feels a lot more > robust than a JSP/JSTL/Ajax/Struts combo. > Thanks to the Wicket team for this excellent framework ! And you, thanks for being part of the community! Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
You are wrong. I have a component (Panel) that has a method to return a
Fragment. This component returns a default implementation of that Fragment,
but pages can override that Fragment.
CRUDFormPanel extends Panel {
protected Fragment newFormFields(String id, Form form) {
if (property == null)
return null;
Fragment f = new Fragment(id, "defaultFormFields",
ListFormPanel.this);
RequiredTextField desc = new RequiredTextField("property",
new PropertyModel(form.getModel(), property));
desc.add(StringValidator.maximumLength(255));
f.add(desc);
f.add(new Label("propertyLabel", getString("propertyLabel")));
form.add(new ObjectExistanceValidator(service, desc, property));
return f;
}
// more code
}
Pages that want to have more fields in this form, can provide another
Fragment.
MyCustomPage extends WebPage {
MyCustomPage() {
add(new CRUDFormPanel("panel") {
protected Fragment newFormFields(String id, Form form) {
Fragment f = new Fragment(id, "customFormFields",
MyCustomPage.this);
RequiredTextField field = new
RequiredTextField("anotherProperty",
new PropertyModel(form.getModel(), "anotherProperty"));
desc.add(StringValidator.maximumLength(50));
f.add(field);
form.add(new ObjectExistanceValidator(service, desc, property));
return f;
}
});
}
}
This is how I override tags with vanilla Wicket. Do we really need another
markup?!
On Nov 7, 2007 4:51 PM, Chris Colman <[EMAIL PROTECTED]> wrote:
> > a lot of people are saying that this can be implemented with panels,
> > and that is true. but actually implementing this with fragments will
> > make it look very similar to this new strategy and does not have the
> > id collission problem, because components ARE nested in two different
> > containers:
>
> I've never used fragments but I just read up on them...
>
> I may be wrong but it looks as if you have to define all possible
> fragments that might appear in a page to that page. It doesn't seem to
> follow the natural, organic flow of markup inheritance where a base page
> can be enhanced by substituting base a page section with markup defined
> in derived/extended pages - that only happens with the child/extends
> feature from my understanding.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
RE: Multiple tags on a single base page?
> > Given these subtle problems with this approach, I admit I'm warming to > > the multiple extend/child idea. > > im oposite - if i have X extends in a page, whose extend should be > preferred (e.g: manipulating the head or a part outside of itself) ? I'm not sure I understand the issue you raise but so please forgive me if I've misunderstood: Presumably you don't have an issue with multiple abstract methods in Java classes? As Java and Wicket only support single inheritance there is no issue as to which base class/page child section is being extended in a derived class/page (that only ever happens in a multiple inheritance paradigm and no one is proposing we go down that path!) - the identifier of an implements in a derived page will only ever resolve to a single abstract tag in a base page. There's no confusion here I don't believe. In Java you name methods carefully and appropriately and the compiler warns you if you have duplicated a function signature. Same would happen in wicket. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why dioes this error occur?
Every once in awhile if I am clicking around for awhile in the UI of my application I get the following error. What causes this? java.lang.NullPointerException at wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveListenerInterfaceTarget(DefaultRequestTargetResolverStrategy.java:295) at wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveRenderedPage(DefaultRequestTargetResolverStrategy.java:228) at wicket.request.compound.DefaultRequestTargetResolverStrategy.resolve(DefaultRequestTargetResolverStrategy.java:153) at wicket.request.compound.AbstractCompoundRequestCycleProcessor.resolve(AbstractCompoundRequestCycleProcessor.java:48) at wicket.RequestCycle.step(RequestCycle.java:992) at wicket.RequestCycle.steps(RequestCycle.java:1084) at wicket.RequestCycle.request(RequestCycle.java:454) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:219) at wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:262) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6981) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183) -- View this message in context: http://www.nabble.com/Why-dioes-this-error-occur--tf4766684.html#a13633697 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: Multiple tags on a single base page?
On Nov 7, 2007 10:38 AM, Chris Colman <[EMAIL PROTECTED]> wrote: > > How can it get messy when it's not yet possible to do in wicket? i believe it has been shown multiple times already that it CAN be done with vanilla wicket... -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> > And if somebody really needs 5 child areas, something else might be even > > messier than the page's constructor. I rather think that 2, 3 or in rare > > cases even 4 ids could make sense. > > i must disagree - i have a basepage which defines the default layout on a > project, i.e. header, top-nav-container (imprint etc), navigation, > content-left/-right/main, footer - this makes 7 panels which are added on > the > way down to the resulting page... > > but i don't use abstract methods for this, for it can get messy (as stated > in other comments). How can it get messy when it's not yet possible to do in wicket? You mention 7 different panels which is > 1 and so not currently supported by wicket's current child/extends feature. Unless you mean that trying to override 7 different sections with only one child/extends feature - but now my brain hurts - the anticipated messiness my be a result of trying to implement multiple specialized sections without support for it being in wicket yet ;) (but given that many people are starting to warm to the idea you might be able to do this sooner rather than later!) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.
im oposite - if i have X extends in a page, whose extend should be
preferred (e.g: manipulating the head or a part outside of itself) ?
my override of onBeforeRender is secure from your point and IMHO more
easy...
John Krasnay schrieb:
On Wed, Nov 07, 2007 at 11:31:12AM +0100, Mats Norén wrote:
Is the above statement really true considering that by adding abstract
methods to your page you defer the creation of the markup in just the
same way as the new proposed solution?
BasePage.java
public BasePage() {
addAbstract1("abstractId1");
addAbstract2("abstractId2);
}
public abstract addAbstract1(String abstractId1);
public abstract addAbstract2(String abstractId2);
BasePage.html
What is the difference between that and doing abstract / implements?
You've just illustrated one of the major problems with the
panel-from-a-subclass approach: it's easy to get it wrong. In your
example, addAbstract1 and addAbstract2 will be called in a class whose
constructor has not yet been called. Consider:
public DerivedPage extends BasePage {
private String name;
public DerivedPage(String name) {
super();
this.name = name;
}
public abstract addAbstract1(String abstractId1) {
add(new NamePanel(abstractId1, name));
}
}
This code is broken, since you're constructing NamePanel before name has
been initialized. Someone later in this thread shows a better way to do
this, by calling the overridable methods from onBeforeRender. But this
is also tricky; because onBeforeRender can be called multiple times you
must maintain a flag to ensure you only add your panels once.
Given these subtle problems with this approach, I admit I'm warming to
the multiple extend/child idea.
jk
-
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: JavaRebel experience
Java Rebel worked for me too. I had no such problem. -- View this message in context: http://www.nabble.com/JavaRebel-experience-tf4695671.html#a13632511 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: Question about localization
application.init() {
getresourcesettings().setlocalizer(...);
}
you dont have to use the default resource model, just write your own
if you dont like the default one.
-igor
On 11/7/07, Pills <[EMAIL PROTECTED]> wrote:
>
> Yes, I'll make it part of the key.
>
> I searched but not found, how can I change the default localizer and the
> default resourcemodel?
>
> There is no method "setLocalizer"/"setResourceModel" in class
> WebApplication...
>
> Thank you for your help.
>
>
> igor.vaynberg wrote:
> >
> > you can override methods in localizer to bend it to your will, but
> > like i said beware if you do not expect to make style part of the key
> >
> > -igor
> >
>
> --
> View this message in context:
> http://www.nabble.com/Question-about-localization-tf4756837.html#a13623105
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> 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: Multiple tags on a single base page?
But the number of added panels needn't be the number of abstract section (though it could). -- stefan Jan Kriesten wrote: > > > hi stefan, > >> And if somebody really needs 5 child areas, something else might be even >> messier than the page's constructor. I rather think that 2, 3 or in rare >> cases even 4 ids could make sense. > > i must disagree - i have a basepage which defines the default layout on a > project, i.e. header, top-nav-container (imprint etc), navigation, > content-left/-right/main, footer - this makes 7 panels which are added on > the > way down to the resulting page... > > but i don't use abstract methods for this, for it can get messy (as stated > in > other comments). > > regards, --- jan. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631624 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: Popup parent comunication
Yes, you must be right, another issue against the modal window is that the
datepicker does not work inside it, and I pretty much decided to stick to
normal popups.
Well it seems that i may have something here:
In the parent page:
add(new AbstractDefaultAjaxBehavior() {
protected void respond(AjaxRequestTarget ajaxRequestTarget) {
System.out.println("Ajax Method invoked");
}
protected void onRenderHeadContribution(final Response response)
{
super.onRenderHeadContribution(response);
StringHeaderContributor header =
new StringHeaderContributor(" " +
"function call() {" +
getCallbackScript(false, true) + "};" +
"");
((WebPage)getComponent().getPage()).add(header);
}
});
In the popup window we have the link:
Link link = new Link("addLink") {
public void onClick() {
System.out.println("Ajax Method invoked");
}
protected CharSequence getOnClickScript(CharSequence
charSequence) {
CharSequence click =
super.getOnClickScript(charSequence);
if(click == null) {
return "self.opener.call();";
}
return click + "self.opener.call();";
}
};
Current problem is that the method sometimes gets invoked sometimes it does
not(the text "Ajax Method invoked" apears on the screen). Actually only the
first time in most cases. The problem must be with the ajax call cause i
added in the call function a debug message in javascript that gets always
called(the call function).
Anybody has any ideas why this is?
Mr Mean wrote:
>
> if your modal dialog contains ajax tabs it should work, but all your
> user interaction from withing the dialog must be ajax.
>
> Maurice
>
> On Nov 7, 2007 1:50 PM, serban.balamaci <[EMAIL PROTECTED]> wrote:
>>
>> I cannot use the modal windows.
>> They are plain popups. I do not know if there is a difference beetween
>> modal
>> windows that have a content a panel or a page, but i need to have tabbed
>> pannels(which are links) inside the popup and by using a modal page with
>> a
>> panel content when i press on another tab(a link), i get the message that
>> "This action requires to navigate away from this page and the modal
>> window
>> will close" and after pressing it does close the modal window.
>>
>> I am currently trying the 3rd option, i think i can write the javascript
>> for
>> the ajax request.
>> I will post the solution if i get it working.
>>
>>
>>
>> Mr Mean wrote:
>> >
>> > Are you using the ModalWindow? in that case you need to set the
>> > PageCreator to return your page, don't use panels. Second you need to
>> > set a callbackhandler for the windowclose event. There you must update
>> > your combo.
>> >
>> > Maurice
>> >
>> > On Nov 7, 2007 12:09 PM, serban.balamaci <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hello!
>> >> I have the following problem. I have a parent page, that opens a popup
>> >> through a PageLink.
>> >> The popup window is a window in which new records can be added, but i
>> >> need a
>> >> combo in the parent page to reflect and contain also the new choice
>> added
>> >> in
>> >> the popup.
>> >>
>> >> 1. Reloading the whole parent page at popup close link pressed i would
>> >> take
>> >> as the last resolve because the user may have introduced data in the
>> >> controls that would get lost in the reloading process. I could get
>> around
>> >> this by adding a submit behaviour to the link and save in session the
>> >> values
>> >> inserted till that moment and rehidrate the model with values from the
>> >> session instead of the database, and so obtain the state that the page
>> >> was
>> >> in before the popup was opened, but i'm wondering if there is not a
>> >> cleaner
>> >> solution for this.
>> >>
>> >> 2. I also tried(didn't think this would work:) but had to try) to pass
>> >> the
>> >> combo to the popup page and tried to update through the pressing of an
>> >> ajaxlink the combo. It said it could not find the markup id for the
>> >> combo(expected since it tried in the popup and not in the parent) so i
>> >> guess
>> >> that this approach could be made valid if the ajax callback would be
>> >> directed at the parent page instead of the popup - i do not know how
>> to
>> >> do
>> >> this.
>> >>
>> >> 3. Another option I am considering is calling a self.opener.function
>> in
>> >> which i would have javascript code for the ajax update of the combo in
>> >> the
>> >> parent. What code that is doing the ajax update i still do not know
>> where
>> >> to
>> >> find-> maybe on the onselectionchange behaviour would be the way to
>> find
>> >> out, or if it breaks something in the way wicket is working
Re: Multiple tags on a single base page?
On Wed, Nov 07, 2007 at 07:14:01PM +0100, Korbinian Bachl wrote: > > Given these subtle problems with this approach, I admit I'm warming to > > the multiple extend/child idea. > > im oposite - if i have X extends in a page, whose extend should be > preferred (e.g: manipulating the head or a part outside of itself) ? Perhaps I don't understand your argument, but it sounds like you're interpreting this as some sort of multiple inheritance thing. I like to look at it this way: - a Wicket page is a Java class and some markup. - there are three ways a page can acquire its markup - it can have its own - it can inherit it from a base class - it can *mostly* inherit it from a base class, but inject some additional markup into the parent markup at a place specified by the parent markup All the current proposal does is allow the parent markup to advertise multiple places where children can inject their markup. Yes, there are difficulties with this. Child pages have to be careful about component ID collisions, the framework has to sort out multiple header contributions from children and grandchildren, etc., but these problems are present in the current single extend/child approach. I can't see any additional ambiguities introduced by allowing additional markup injection sites. > my override of onBeforeRender is secure from your point and IMHO more > easy... I suggest it's not so easy for average Java developers starting out with Wicket. In my experience, many Java developers are unaware of the "don't call non-private, non-final methods from constructors" rule. Further, once you've been bitten by that problem, it's not clear that using onBeforeRender is the answer. And once you've figured *that* out, it's not clear that you have to protect against multiple invocations. jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> Chris Colman schrieb: > > The beauty of the multiple extend/child idea is that it's not a > > completely new concept we're talking about here - it's merely an issue > > of supporting n>1 instead of arbitrarily fixing n=1 like it is now. > > 1 Question: Who dominates Who and Why? > > If you extend 1 class by class you create specialisations that dominate > each other, but here you just mess together some classes - so why should > which class dominate? If we manipulate a headertag? If we have same > namespace? If we have different securitylevels? Wich class is > responsible for all this? Why? Dunno what you mean by "dominate" or "mess together some classes". No one is talking about mess - the whole point of this feature is avoidance of mess - in the same way OO brings about reduced complexity in code the same thing can happen with markup. We're not proposing multiple inheritance - which indeed causes mess. We're talking single inheritance which means single lineage. Each page only has a single base page. It's easy for Wicket to perform the resolutions and merge markup from base and derived pages. I know this because it already does it and it works fine. We're just proposing to remove the restriction that it can only do it for just one section of your base page - that's all, nothing revolutionary - just evolutionary. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help understaning AjaxCallDecorator problem
I remove the decorator and the onClick method does get called (stop in debugger) and the resulting page I end up on is what I expect. The Ajax debug console disappears before I can read what it is saying, and the Javascript console does not report any problems. I will install firebug and see what that can tell me. Thanks!! Timo Rantalaiho wrote: > > Have you checked that onClick() gets called without the > decorator? > > Have you looked at the results on the Javascript console > of Firefox and Javascript debugger of FireBug? > > Have you looked at the wicket Ajax debug window (on > development mode) while clicking? > > I think so, yes, because I think that this is sometimes used > for Javascript confirmation popups. > > Best wishes, > Timo > > -- > Timo Rantalaiho > Reaktor Innovations Oyhttp://www.ri.fi/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Help-understaning-AjaxCallDecorator-problem-tf4760426.html#a13629634 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: Multiple tags on a single base page?
no not the merging of markup. but inside the constructor of the child/sub page. Where do you make all the root components of all the child parts? you will add that to the page itself right? I just say that then it could be a bit messy when you have 5 child area's johan On 11/7/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > > hi johan, > > > Johan Compagner wrote: > > > > 1 thing that does bother me a bit (but maybe i have to do a deeper look > > into > > the patch) how do you separate > > the components in the constructor of the sub page.. i guess you just add > > all > > the components over all the child fragments > > in the page itself. That's not a nice separation... That can lead to big > a > > big mess.. Because what component belong to what child part. " > > > > I don't get what you mean here. However, my implementation is closely > related to Juergen's MergedMarkup.java (and admittedly partially copied) > and > does the same. > > - > --- > Stefan Fußenegger > http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > -- > View this message in context: > http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154 > 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: Multiple tags on a single base page?
i do see your point, but it is not that much different, its just another way
of doing stuff.
Markup inheritance does come from the border stuff. i think i was the one
that proposes it when
we had a meeting here now a few years ago here in Holland so that that we
could border pages.
Then Juergen did implement it..
The thing that the multiply child's solve is that you can have the markup in
the sub page itself
instead of in panels. You can currently have the markup in the sub page (as
fragments), but
then you also have to define . Else the sub page would
override the complete
base page markup.
But we can see for 1.4 if we can incorporate it into the core. But do make
sure that we don't
create a lot more tags, which is not the case as far as i see. So just just
that name attribute tag tags the specific parts.
1 thing that does bother me a bit (but maybe i have to do a deeper look into
the patch) how do you separate
the components in the constructor of the sub page.. i guess you just add all
the components over all the child fragments
in the page itself. That's not a nice separation... That can lead to big a
big mess.. Because what component belong to what child part.
And the previewability is a bit of mess if you would have 5 childs in your
sub page.
That are then just "random" blocks of html.
johan
On 11/7/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>
>
> Well, if naming is your only concern, the attribute's name can easily be
> replaced with something else than id ... e.g. name
>
>
>
>
> some text
>
>
> and remember that they can be optional as well:
>
>
>
>
> some text
>
>
> This way, its completely compatible with child/extend (which can be
> proofed
> with the existing junit test for markup inheritance)
>
> just a question: do i start to convince you? ;)
>
> best regards
>
>
> Bruno Borges wrote:
> >
> > Let me paste what I commented in WICKET-1134:
> >
> > *I think this improvement is just more of a way to "override" components
>
> > declared in markups of a super class. Because this is what really
> happens.
> > Let's check your example:
> >
> > In the BasePage, there are two fragments:
> > - subNavigation
> > - content
> >
> > What about if I want to have a fragment in SectionPage with id
> "content",
> > but not related with that content from BasePage? You see, the concept of
> > extend/child, is the same as in OOP's inheritance. What goes in child,
> is
> > from the subclass. Period.
> >
> > In Java, if you declare:
> > class BasePage ... {
> > protected Object someProperty;
> > }
> >
> > class SectionPage extends BasePage {
> > protected Object someProperty;
> > }
> >
> > What happens here is that SectionPage.someProperty does NOT
> > override/implement/whatever-you-wanna-call, BasePage.someProperty. What
> > you
> > want to do in HTML would be this in Java.
> >
> > I'm worry about people trying to subclass some WebMarkupContainer, and
> > having to be carefully with components ids, just to _not_ match
> something
> > that would generate strange output.
> >
> > If in SectionPage I add some component (like Label) with "content" id,
> > what
> > would happen? Throw a message: "You cannot use this id because there's
> an
> > abstract 'content' markup in BasePage.html". This would lead to code in
> > HTML
> > that has NO reference within it's Java class.
> >
> > This means that: what you don't see in Java, it *might* be possible to
> > exist
> > in the HTML.
> >
> > And what I like most of Wicket, is its ability to let me take control of
> > everything, just from one source: Java. But if I'm going to be obligated
> > of
> > taking care of what people declare in HTML files that I can't see in
> some
> > Java source code, then I will reconsider my framework's choice.
> >
> > Regards*
> >
> > Now, Stefan, let me reply your last comment in the issue:
> > *No, ids used with abstract/implement are completely different from
> > wicket:ids ... they are only used to construct (i.e. merge ... or link)
> > the
> > markup, so it is perfectly legal to use when there
> > is
> > a somewhere, as they won't be related.
> > Therefore,
> > no of the concerns you mention would apply, as ...
> >
> > The concept of abstract/implement is the same as in OOP's inheritance.
> > What
> > goes in child, is from the subclass! Exclamation mark! ;)*
> >
> > Ok, you propose a new attribute for extend/abstract, child/implement
> pair
> > tags. And you say that this id attribute will NOT have any relationship
> > with
> > wicket:id. Well, isn't this something... scary? The documentation will
> > have
> > to take care of this, because it will _not_ be intuitive.
> >
> > Regards,
> >
> >
> > On Nov 7, 2007 10:15 AM, Stefan Fußenegger <[EMAIL PROTECTED] >
> > wrote:
> >
> >>
> >> Hi Mats, let me try to explain what Chris and I see here that others
> >> don't
> >> -
> >> may it be there or not ;)
> >>
> >> You can of course do everything with panels that could be done with
> >> multiple
> >> abstract sections
Re: Multiple tags on a single base page?
huh why would java code define the layout in this example?
you still have the html of the page that does the layout of those panels
and the content of those panels are layout with the markup of those panels.
Layout in java would be something like:
component.setSize()
component.setLayout()
johan
On 11/7/07, Chris Colman <[EMAIL PROTECTED]> wrote:
>
> > and in extending classes you can easily do this:
> >
> > protected void initialize() {
> >
> > addToAnything(new AnyPanel("id"));
> > addToAnything(new AnyPanel2("id2"));
> > }
>
> So now you're proposing the Java code is defining the layout of
> components? That's what the markup's job is I thought.
>
> What I, and probably many others, like about wicket is that the Java
> code is just a "slave" to the markup - not the other way around. The
> graphic designers are free to control where everything goes in markup
> and so long as I have implemented a Java class for each panel that they
> want to use then everything just works. They can rearrange the whole
> look and layout of the side without me touching my Java code.
>
> Your solution is starting to look very much like the Echo2 solution -
> where layout is controlled entirely in Java.
>
> Also: Does your addToAnything method assume a regular, repeating pattern
> - like panels in a column or row? What if the panels I want to
> specialize in derived pages are not laid out in a grid or array
> structure: eg., a sub header that spans the entire page width plus a
> side menu on the left plus a body section in the middle - all separately
> implemented at various levels in the page hierarchy but with the
> structural HTML that lays them out specified in one place in the base
> page?
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Multiple tags on a single base page?
Well, if naming is your only concern, the attribute's name can easily be
replaced with something else than id ... e.g. name
some text
and remember that they can be optional as well:
some text
This way, its completely compatible with child/extend (which can be proofed
with the existing junit test for markup inheritance)
just a question: do i start to convince you? ;)
best regards
Bruno Borges wrote:
>
> Let me paste what I commented in WICKET-1134:
>
> *I think this improvement is just more of a way to "override" components
> declared in markups of a super class. Because this is what really happens.
> Let's check your example:
>
> In the BasePage, there are two fragments:
> - subNavigation
> - content
>
> What about if I want to have a fragment in SectionPage with id "content",
> but not related with that content from BasePage? You see, the concept of
> extend/child, is the same as in OOP's inheritance. What goes in child, is
> from the subclass. Period.
>
> In Java, if you declare:
> class BasePage ... {
> protected Object someProperty;
> }
>
> class SectionPage extends BasePage {
> protected Object someProperty;
> }
>
> What happens here is that SectionPage.someProperty does NOT
> override/implement/whatever-you-wanna-call, BasePage.someProperty. What
> you
> want to do in HTML would be this in Java.
>
> I'm worry about people trying to subclass some WebMarkupContainer, and
> having to be carefully with components ids, just to _not_ match something
> that would generate strange output.
>
> If in SectionPage I add some component (like Label) with "content" id,
> what
> would happen? Throw a message: "You cannot use this id because there's an
> abstract 'content' markup in BasePage.html". This would lead to code in
> HTML
> that has NO reference within it's Java class.
>
> This means that: what you don't see in Java, it *might* be possible to
> exist
> in the HTML.
>
> And what I like most of Wicket, is its ability to let me take control of
> everything, just from one source: Java. But if I'm going to be obligated
> of
> taking care of what people declare in HTML files that I can't see in some
> Java source code, then I will reconsider my framework's choice.
>
> Regards*
>
> Now, Stefan, let me reply your last comment in the issue:
> *No, ids used with abstract/implement are completely different from
> wicket:ids ... they are only used to construct (i.e. merge ... or link)
> the
> markup, so it is perfectly legal to use when there
> is
> a somewhere, as they won't be related.
> Therefore,
> no of the concerns you mention would apply, as ...
>
> The concept of abstract/implement is the same as in OOP's inheritance.
> What
> goes in child, is from the subclass! Exclamation mark! ;)*
>
> Ok, you propose a new attribute for extend/abstract, child/implement pair
> tags. And you say that this id attribute will NOT have any relationship
> with
> wicket:id. Well, isn't this something... scary? The documentation will
> have
> to take care of this, because it will _not_ be intuitive.
>
> Regards,
>
>
> On Nov 7, 2007 10:15 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
> wrote:
>
>>
>> Hi Mats, let me try to explain what Chris and I see here that others
>> don't
>> -
>> may it be there or not ;)
>>
>> You can of course do everything with panels that could be done with
>> multiple
>> abstract sections (may they be named wicket:child or wicket:abstract).
>> However, if this is the only argument, you wouldn't need markup
>> inheritance
>> at all! The proposed change is just an extension of exactly this markup
>> inheritance concept (that everybody loves) to make it even more powerful
>> than it already is.
>>
>> I was quite new to wicket (which I still am) and came across a situation
>> where I wanted to use two abstract sections: one for a sub-navigation
>> that
>> was common for several pages in a section and one for the actual content.
>> For me, as a wicket newbie, it would have been most natural to use markup
>> inheritance to solve this problem. Using abstract methods, while being a
>> nice solution (workaround?), didn't come to my mind at once, nor did I
>> find
>> it somewhere in the docs.
>>
>> imho, there are two possible solution to this problem:
>> 1. promote using abstract methods for this in the docs as the wicket-way
>> of
>> doing it
>> 2. extend the current markup inheritance mechanism (which I tried to do
>> with
>> my patch/prototype)
>>
>> -- stefan
>>
>>
>> Mats Norén-2 wrote:
>> >
>> > On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
>> >> Hmm...I'm interested in seeing the difference as well. I would love to
>> >> get it but right now I don't.
>> >>
>> >> Chris Colman wrote:
>> >> "This new feature, or extension of the exiting feature, allows more
>> than
>> >> one section of markup to be "specialized" by derived (extended)
>> markups
>> >> whereas currently wicket only supports the deferred
>> >> definition/implementation of a single markup s
Re: Multiple tags on a single base page?
I can see how and tags could be a nice enhancement to the current and tags. Do you have a working, or mostly working, patch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Let me paste what I commented in WICKET-1134:
*I think this improvement is just more of a way to "override" components
declared in markups of a super class. Because this is what really happens.
Let's check your example:
In the BasePage, there are two fragments:
- subNavigation
- content
What about if I want to have a fragment in SectionPage with id "content",
but not related with that content from BasePage? You see, the concept of
extend/child, is the same as in OOP's inheritance. What goes in child, is
from the subclass. Period.
In Java, if you declare:
class BasePage ... {
protected Object someProperty;
}
class SectionPage extends BasePage {
protected Object someProperty;
}
What happens here is that SectionPage.someProperty does NOT
override/implement/whatever-you-wanna-call, BasePage.someProperty. What you
want to do in HTML would be this in Java.
I'm worry about people trying to subclass some WebMarkupContainer, and
having to be carefully with components ids, just to _not_ match something
that would generate strange output.
If in SectionPage I add some component (like Label) with "content" id, what
would happen? Throw a message: "You cannot use this id because there's an
abstract 'content' markup in BasePage.html". This would lead to code in HTML
that has NO reference within it's Java class.
This means that: what you don't see in Java, it *might* be possible to exist
in the HTML.
And what I like most of Wicket, is its ability to let me take control of
everything, just from one source: Java. But if I'm going to be obligated of
taking care of what people declare in HTML files that I can't see in some
Java source code, then I will reconsider my framework's choice.
Regards*
Now, Stefan, let me reply your last comment in the issue:
*No, ids used with abstract/implement are completely different from
wicket:ids ... they are only used to construct (i.e. merge ... or link) the
markup, so it is perfectly legal to use when there is
a somewhere, as they won't be related. Therefore,
no of the concerns you mention would apply, as ...
The concept of abstract/implement is the same as in OOP's inheritance. What
goes in child, is from the subclass! Exclamation mark! ;)*
Ok, you propose a new attribute for extend/abstract, child/implement pair
tags. And you say that this id attribute will NOT have any relationship with
wicket:id. Well, isn't this something... scary? The documentation will have
to take care of this, because it will _not_ be intuitive.
Regards,
On Nov 7, 2007 10:15 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
wrote:
>
> Hi Mats, let me try to explain what Chris and I see here that others don't
> -
> may it be there or not ;)
>
> You can of course do everything with panels that could be done with
> multiple
> abstract sections (may they be named wicket:child or wicket:abstract).
> However, if this is the only argument, you wouldn't need markup
> inheritance
> at all! The proposed change is just an extension of exactly this markup
> inheritance concept (that everybody loves) to make it even more powerful
> than it already is.
>
> I was quite new to wicket (which I still am) and came across a situation
> where I wanted to use two abstract sections: one for a sub-navigation that
> was common for several pages in a section and one for the actual content.
> For me, as a wicket newbie, it would have been most natural to use markup
> inheritance to solve this problem. Using abstract methods, while being a
> nice solution (workaround?), didn't come to my mind at once, nor did I
> find
> it somewhere in the docs.
>
> imho, there are two possible solution to this problem:
> 1. promote using abstract methods for this in the docs as the wicket-way
> of
> doing it
> 2. extend the current markup inheritance mechanism (which I tried to do
> with
> my patch/prototype)
>
> -- stefan
>
>
> Mats Norén-2 wrote:
> >
> > On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
> >> Hmm...I'm interested in seeing the difference as well. I would love to
> >> get it but right now I don't.
> >>
> >> Chris Colman wrote:
> >> "This new feature, or extension of the exiting feature, allows more
> than
> >> one section of markup to be "specialized" by derived (extended) markups
> >> whereas currently wicket only supports the deferred
> >> definition/implementation of a single markup section in any page. In
> >> other words we want to make a powerful feature even more powerful."
> >>
> >> Is the above statement really true considering that by adding abstract
> >> methods to your page you defer the creation of the markup in just the
> >> same way as the new proposed solution?
> >>
> >> BasePage.java
> >>
> >> public BasePage() {
> >> addAbstract1("abstractId1");
> >> addAbstract2("abstractId2);
> >> }
> >>
> >> public abstract addAbstract1(String abstractId1);
> >> public abstract addAbstract2(String abstractId2);
> >
> > A little typo here..I meant:
> >
> > public BasePage() {
> > add(addAbstract
Re: Why dioes this error occur?
Hi. Well in my case this error apeared when the user clicked on a link that was directing the user to the next page, and while the user did not wait for the other page to load, or he thought that he did not press the mouse button and he clicked again. The server saw that the component(link) was no longer in the the new page and therefore the nullpointer. I got around this by disabling the link after the clicking. salmas wrote: > > Every once in awhile if I am clicking around for awhile in the UI of my > application I get the following error. What causes this? > > java.lang.NullPointerException > at > wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveListenerInterfaceTarget(DefaultRequestTargetResolverStrategy.java:295) > at > wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveRenderedPage(DefaultRequestTargetResolverStrategy.java:228) > at > wicket.request.compound.DefaultRequestTargetResolverStrategy.resolve(DefaultRequestTargetResolverStrategy.java:153) > at > wicket.request.compound.AbstractCompoundRequestCycleProcessor.resolve(AbstractCompoundRequestCycleProcessor.java:48) > at wicket.RequestCycle.step(RequestCycle.java:992) > at wicket.RequestCycle.steps(RequestCycle.java:1084) > at wicket.RequestCycle.request(RequestCycle.java:454) > at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:219) > at wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:262) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) > at > weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) > at > weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348) > at > weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6981) > at > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) > at > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) > at > weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892) > at > weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766) > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224) > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183) > -- View this message in context: http://www.nabble.com/Why-dioes-this-error-occur--tf4766684.html#a13634076 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: Multiple tags on a single base page?
> > How can it get messy when it's not yet possible to do in wicket? > > i believe it has been shown multiple times already that it CAN be done > with vanilla wicket... I didn't like the look of any of those 'coded' solutions. They were not from the coding elegance book I've read. They also mean I'm starting to arrange, layout and compose my pages in Java instead of markup (meaning my graphic designers lose control). The abilty to control layout completely at the markup level instead of the Java level is why I moved to Wicket from another framework in the first place and I guess a lot of others have too. The division of responsibility in Wicket is something not achieved by any other framework I have used which is great because I don't think I'm going to be able to teach my graphic designers Java any time soon. I also wouldn't classify as "vanilla" that alternative, workaround using low level plumbing code that hooks into the lifecycle methods. It's more like a honeycomb chocolate fudge, banana sundae, with 1" thick caramel sauce sprinkled with 100s and 1000s ;) - it sounds great on the menu but after you've finished it you're left wondering if you made the right decision. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why dioes this error occur?
Hi salmas, On 07 November 2007, 7:05:26 PM, salmas wrote: s> Every once in awhile if I am clicking around for awhile in the UI of my s> application I get the following error. What causes this? s> java.lang.NullPointerException s> at s> wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveListenerInterfaceTarget(DefaultRequestTargetResolverStrategy.java:295) What version of Wicket are you using? -- /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> a lot of people are saying that this can be implemented with panels, > and that is true. but actually implementing this with fragments will > make it look very similar to this new strategy and does not have the > id collission problem, because components ARE nested in two different > containers: I've never used fragments but I just read up on them... I may be wrong but it looks as if you have to define all possible fragments that might appear in a page to that page. It doesn't seem to follow the natural, organic flow of markup inheritance where a base page can be enhanced by substituting base a page section with markup defined in derived/extended pages - that only happens with the child/extends feature from my understanding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help understaning AjaxCallDecorator problem
On Wed, 07 Nov 2007, skatz wrote: > The Ajax debug console disappears before I can read what it is saying, and Hmm, I think that normally the ajax debug console should stay there for javascript executions and ajax requests. Could it be that the whole page gets loaded somehow? Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Sebastiaan van Erk schrieb: Korbinian Bachl wrote: you missed solution3: the real-wicket-way(tm) for multiple content-places in a tied page-area: Whaaa, I seriously hope this is not the real-wicket-way! My brain hurts! maybe you should go to a doctor then?... A framework is supposed to make things easy and readable! The code below is just way too complicated to achieve something that should be easy... whats difficult here? it gives you maximum flexibility and was just a example(tm) which can be further simplified if you use other container types - this was showed to me by Igor some time ago and it has proven its success for me... Preferably when doing simple stuff like this, I don't want to be confronted with things like rendering (and adding render hooks), or with keeping extra state about components being or not being initalized. Also I don't want to have to copy this boiler plate for every time I want to place some kind of component "hole" in a base page! usually this kind of code is present at 1 place within a project, not in every class, just the raw baseclass (maybe in 2 baseclasses if you have a designer who wants to have 2 completely different markups for 1 project) - compared to other existing poblems of webdeveloping (like security and authorization) these 2-minutes i spend on this at all is not really mattering... Best, Korbinian Regards, Sebastiaan eg: html: ... Place to put anything -zip- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Igor Vaynberg wrote:
... actually implementing this with fragments will
make it look very similar to this new strategy and does not have the
id collission problem, because components ARE nested in two different
containers:
class basepage extends webpage {
Fragment templateFoo1(String id) { return new emptyfragment(id); }
Fragment templateFoo2(String id) { return new emptyfragment(id); }
}
thoughts?
I've finally got around to reading (most) of this insanely long thread.
My first thought was, "why don't you just use Fragments for this?"
Obviously the person who extends BasePage needs to know what fragment
IDs they should be adding in.
But then, with the proposed extra tag, they'd need to
know what IDs to be using, so I can't see much
difference here.
The only issue is that you need to actually add some code, which you
don't with a pure tag-based solution.
On the other hand, you probably need to add some code anyway - I can't
think of many use-cases where you'd want to only put mark-up in one or
more of your blocks that isn't better handled using
localization with keys being overridden for the various
pages.
Regards,
Al
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Thanks for giving the best overview of my thoughts Igor. Are you reading my
mind?
On Nov 7, 2007 3:50 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> let me weigh in with my thoughts on this.
>
> a big problem with markup inheritance is the possibility of id collissions
>
> for example
>
> class basepage extends webpage {
> public basepage() {
>add(new label("label"));
> }
> }
>
> class concretepage extends basepage {
> public concretepage() {
>add(new label("label"));
> }
> }
>
> basepage:
> concretepage:
>
> now what you are proposing here makes this collission possibility
> significantly higher because essentially i CANNOT even have something
> like this:
>
>
>
>
> even though to me it looks like the nasting of foo1 and foo2 are
> seperate so i should be able to have a direct child with the same id
> in bothbut i cannot.
>
> a lot of people are saying that this can be implemented with panels,
> and that is true. but actually implementing this with fragments will
> make it look very similar to this new strategy and does not have the
> id collission problem, because components ARE nested in two different
> containers:
>
> class basepage extends webpage {
> Fragment templateFoo1(String id) { return new emptyfragment(id); }
> Fragment templateFoo2(String id) { return new emptyfragment(id); }
> }
>
> wicket:id="label">
> wicket:id="label">
>
> thoughts?
>
> -igor
>
>
>
>
> On 11/2/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
> >
> > Hi folks,
> >
> > I just stumbled on a situation where it would be useful to have two or
> more
> > tags in a base page. Just consider a layout that
> consists
> > of the usual footer, header, navigation, and content parts. But now, the
> > content should be arranged in two columns, e.g. two different s.
> >
> > To give a short example, the BasePage.html cloud look like this
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > And the Child.html markup would look like this:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Wouldn't that be a desirable feature? I tried to run the above example
> > expecting to get an exception. The second wicket:child/wicket:extend
> pair
> > was happily ignored though.
> >
> > Best regards, Stefan
> > --
> > View this message in context:
> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > -
> > 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]
>
>
--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
Re: Multiple tags on a single base page?
>
> just a question: do i start to convince you? ;)
>
No... you are not... :D far far away from that
But don't take it personal, my opinion is technical... only!
On Nov 7, 2007 11:29 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
wrote:
>
> Well, if naming is your only concern, the attribute's name can easily be
> replaced with something else than id ... e.g. name
>
>
>
>
> some text
>
>
> and remember that they can be optional as well:
>
>
>
>
> some text
>
>
> This way, its completely compatible with child/extend (which can be
> proofed
> with the existing junit test for markup inheritance)
>
> just a question: do i start to convince you? ;)
>
> best regards
>
>
> Bruno Borges wrote:
> >
> > Let me paste what I commented in WICKET-1134:
> >
> > *I think this improvement is just more of a way to "override" components
> > declared in markups of a super class. Because this is what really
> happens.
> > Let's check your example:
> >
> > In the BasePage, there are two fragments:
> > - subNavigation
> > - content
> >
> > What about if I want to have a fragment in SectionPage with id
> "content",
> > but not related with that content from BasePage? You see, the concept of
> > extend/child, is the same as in OOP's inheritance. What goes in child,
> is
> > from the subclass. Period.
> >
> > In Java, if you declare:
> > class BasePage ... {
> > protected Object someProperty;
> > }
> >
> > class SectionPage extends BasePage {
> > protected Object someProperty;
> > }
> >
> > What happens here is that SectionPage.someProperty does NOT
> > override/implement/whatever-you-wanna-call, BasePage.someProperty. What
> > you
> > want to do in HTML would be this in Java.
> >
> > I'm worry about people trying to subclass some WebMarkupContainer, and
> > having to be carefully with components ids, just to _not_ match
> something
> > that would generate strange output.
> >
> > If in SectionPage I add some component (like Label) with "content" id,
> > what
> > would happen? Throw a message: "You cannot use this id because there's
> an
> > abstract 'content' markup in BasePage.html". This would lead to code in
> > HTML
> > that has NO reference within it's Java class.
> >
> > This means that: what you don't see in Java, it *might* be possible to
> > exist
> > in the HTML.
> >
> > And what I like most of Wicket, is its ability to let me take control of
> > everything, just from one source: Java. But if I'm going to be obligated
> > of
> > taking care of what people declare in HTML files that I can't see in
> some
> > Java source code, then I will reconsider my framework's choice.
> >
> > Regards*
> >
> > Now, Stefan, let me reply your last comment in the issue:
> > *No, ids used with abstract/implement are completely different from
> > wicket:ids ... they are only used to construct (i.e. merge ... or link)
> > the
> > markup, so it is perfectly legal to use when there
> > is
> > a somewhere, as they won't be related.
> > Therefore,
> > no of the concerns you mention would apply, as ...
> >
> > The concept of abstract/implement is the same as in OOP's inheritance.
> > What
> > goes in child, is from the subclass! Exclamation mark! ;)*
> >
> > Ok, you propose a new attribute for extend/abstract, child/implement
> pair
> > tags. And you say that this id attribute will NOT have any relationship
> > with
> > wicket:id. Well, isn't this something... scary? The documentation will
> > have
> > to take care of this, because it will _not_ be intuitive.
> >
> > Regards,
> >
> >
> > On Nov 7, 2007 10:15 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
> > wrote:
> >
> >>
> >> Hi Mats, let me try to explain what Chris and I see here that others
> >> don't
> >> -
> >> may it be there or not ;)
> >>
> >> You can of course do everything with panels that could be done with
> >> multiple
> >> abstract sections (may they be named wicket:child or wicket:abstract).
> >> However, if this is the only argument, you wouldn't need markup
> >> inheritance
> >> at all! The proposed change is just an extension of exactly this markup
> >> inheritance concept (that everybody loves) to make it even more
> powerful
> >> than it already is.
> >>
> >> I was quite new to wicket (which I still am) and came across a
> situation
> >> where I wanted to use two abstract sections: one for a sub-navigation
> >> that
> >> was common for several pages in a section and one for the actual
> content.
> >> For me, as a wicket newbie, it would have been most natural to use
> markup
> >> inheritance to solve this problem. Using abstract methods, while being
> a
> >> nice solution (workaround?), didn't come to my mind at once, nor did I
> >> find
> >> it somewhere in the docs.
> >>
> >> imho, there are two possible solution to this problem:
> >> 1. promote using abstract methods for this in the docs as the
> wicket-way
> >> of
> >> doing it
> >> 2. extend the current markup inheritance mechanism (which I tried to do
> >> with
> >> my patch/prototype)
> >>
> >> -- stefan
> >>
RE: Multiple tags on a single base page?
Presumably the coded work arounds that don't rely on child/extends mean that the structural markup of each page is used instead of just that of the base page - and that would spell maintenance issues. Without using child/extend then ALL the structural markup in each page is used for each render - NOTHING is pulled from the base page markup (kind of makes me wonder why we need base page markup if not using child/extend - but that's another topic!). A change of layout structure would mean changing all page markups - yuck - or do you guys not care about your graphics designers - "arh, that's their problem if they want to do a site wide change!" I think the fundamental thing that most people are missing is that each component must be well formed XHTML, complete and self contained. If it starts a (or ) then it must also end it. Divs (and tables) are the basic structural elements of markup. One component can't be the start of a structural span of markup, the next few components content sections for that span and then the last component ends the structural span - that is not possible because each component must be well formed and complete. So this infers that structural markup typically is stored in page markup and "wraps" markup that inserts various self contained components. Now here's the thing: without using child/extends then that structural markup must be carefully defined in EVERY page markup because wicket does not do the funky inheritance merging when you don't use the child/extends tag. So if you want to change a border in between two components you must change it in EVERY page markup. That would suck. Alternatively, if you do use the current child/extend you end up having to bang multiple components into the overridden section which means that you also bang in the border that exists between them - so now the border markup is duplicated many times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Korbinian Bachl wrote:
you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied page-area:
Whaaa, I seriously hope this is not the real-wicket-way! My brain hurts!
A framework is supposed to make things easy and readable! The code below
is just way too complicated to achieve something that should be easy...
Preferably when doing simple stuff like this, I don't want to be
confronted with things like rendering (and adding render hooks), or with
keeping extra state about components being or not being initalized. Also
I don't want to have to copy this boiler plate for every time I want to
place some kind of component "hole" in a base page!
Regards,
Sebastiaan
eg: html:
...
Place to put anything
...
java:
public abstract MyPage extends AnyPageExtendingWicketsWebPage {
private boolean initialized = false;
private final RepeatingView anything;
MyPage() {
super();
anything = new RepeatingView("anything");
add(anything);
}
/**
* Abstract place to add content to the containers
*/
protected abstract void initialize();
@Override
protected void onBeforeRender() {
super.onBeforeRender();
if(!initialized) {
initialize();
initialized = true;
}
}
/**
* Adds the content-Component c to Column A
* (the smaller one on the left)
*
* @return
*/
public void addToAnthing(Component c) {
c.setRenderBodyOnly(true);
getAnything().addOrReplace(c);
}
public RepeatingView getAything() {
return anything;
}
}
and in extending classes you can easily do this:
protected void initialize() {
addToAnything(new AnyPanel("id"));
addToAnything(new AnyPanel2("id2"));
}
etc.
this is maximum flexible, fast implemented, beeing checked by the IDE
and nice OO behaviour as it allows you to chain this over several
levels, plus it aids you when it comes to security-limitations as you
have a logic hirarchy where you can use each step for more restricted
access-rules
e.g: BasePage -> SecureBasePage -> HighlySecuredBasePage -> MyPage
if you then need a panel manipulating other areas this is easily done by:
e.g:
(MyPage getPage()).getAnything().doWhatYouWantToDo(WhatYouWant)
(you could also make this final thing abstract and then only override it
in the page you place it in wich gives even more control and makes it
reusable over projects)
and this is sth. that happens more often than you expect IMHO
plus the biggest advancement: the HTML tied to the classes stays clean
and is not poluted with some fancy tags (wich is the bigest plague in
the Javaworld IMHO... i never understood how they could invent things
like JSP or JSF that are worse to even PHP code in a page)
Best
Korbinian
Stefan Fußenegger schrieb:
Hi Mats, let me try to explain what Chris and I see here that others
don't -
may it be there or not ;)
You can of course do everything with panels that could be done with
multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you wouldn't need markup
inheritance
at all! The proposed change is just an extension of exactly this markup
inheritance concept (that everybody loves) to make it even more powerful
than it already is.
I was quite new to wicket (which I still am) and came across a situation
where I wanted to use two abstract sections: one for a sub-navigation
that
was common for several pages in a section and one for the actual content.
For me, as a wicket newbie, it would have been most natural to use markup
inheritance to solve this problem. Using abstract methods, while being a
nice solution (workaround?), didn't come to my mind at once, nor did I
find
it somewhere in the docs.
imho, there are two possible solution to this problem:
1. promote using abstract methods for this in the docs as the
wicket-way of
doing it
2. extend the current markup inheritance mechanism (which I tried to
do with
my patch/prototype)
-- stefan
Mats Norén-2 wrote:
On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
Hmm...I'm interested in seeing the difference as well. I would love to
get it but right now I don't.
Chris Colman wrote:
"This new feature, or extension of the exiting feature, allows more
than
one section of markup to be "specialized" by derived (extended) markups
whereas currently wicket only supports the deferred
definition/implementation of a single markup section in any page. In
other words we want to make a powerful feature even more powerful."
Is the above statement really true considering that by adding abstract
methods to your page you defer the creation of the markup in just the
same way as the new proposed solution?
BasePage.java
public BasePage() {
addAbstract1("abstractId1");
addAbstract2("abstractId2);
}
public abstract addAbstract1(String abstractId1);
public abstract addAb
Re: Multiple tags on a single base page?
On Wed, Nov 07, 2007 at 11:31:12AM +0100, Mats Norén wrote:
>
> Is the above statement really true considering that by adding abstract
> methods to your page you defer the creation of the markup in just the
> same way as the new proposed solution?
>
> BasePage.java
>
> public BasePage() {
> addAbstract1("abstractId1");
> addAbstract2("abstractId2);
> }
>
> public abstract addAbstract1(String abstractId1);
> public abstract addAbstract2(String abstractId2);
>
>
> BasePage.html
>
>
>
>
> What is the difference between that and doing abstract / implements?
You've just illustrated one of the major problems with the
panel-from-a-subclass approach: it's easy to get it wrong. In your
example, addAbstract1 and addAbstract2 will be called in a class whose
constructor has not yet been called. Consider:
public DerivedPage extends BasePage {
private String name;
public DerivedPage(String name) {
super();
this.name = name;
}
public abstract addAbstract1(String abstractId1) {
add(new NamePanel(abstractId1, name));
}
}
This code is broken, since you're constructing NamePanel before name has
been initialized. Someone later in this thread shows a better way to do
this, by calling the overridable methods from onBeforeRender. But this
is also tricky; because onBeforeRender can be called multiple times you
must maintain a flag to ensure you only add your panels once.
Given these subtle problems with this approach, I admit I'm warming to
the multiple extend/child idea.
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help understaning AjaxCallDecorator problem
So the ultimate result of the onClick() method, in this case, is to move to a whole new page, i.e the last line is: setResponsePage(...);, so technically, it probably does not need to be an ajax request, but because of the way we are reusing some code it is. I commented out the setResponsePage() as a test and the Ajax Console still disappeared. Timo Rantalaiho wrote: > > On Wed, 07 Nov 2007, skatz wrote: >> The Ajax debug console disappears before I can read what it is saying, >> and > > Hmm, I think that normally the ajax debug console should > stay there for javascript executions and ajax requests. > Could it be that the whole page gets loaded somehow? > > Best wishes, > Timo > > -- > Timo Rantalaiho > Reaktor Innovations Oyhttp://www.ri.fi/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Help-understaning-AjaxCallDecorator-problem-tf4760426.html#a13635149 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: Problem closing a ModalWindow when used through an IFrame
Have you noticed that if you try to close the example window from OK or
CANCEL button it closes even when used through an iframe?
By using firebug, you can place breakpoints to modal.js and see that this
code is executed when the window is closed from OK button:
org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
On line 699:
if (this.isIframe() == true) {
var current =
this.content.contentWindow.Wicket.Window.current;
On line 715
close: function(force) {
... etc
But the above code is not executed when the modal window is closed from the
X button on upper right corner of the window.
Could it solve the problem if the same close function would be executed from
the X-button too?
On Nov 1, 2007 12:14 PM, 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
> http://localhost:8080/mywicketapp/app/"; width="100%"
> height="500">
>
> 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
>
Re: eHour migrated to Wicket
Good looking app. What kinds of lessons did you learn in the migration? It would be interesting to collect them into a wiki page. -- Nick Heudecker Professional Wicket Training & Consulting http://www.systemmobile.com Eventful - Intelligent Event Management http://www.eventfulhq.com
Re: Popup parent comunication
Are you using the ModalWindow? in that case you need to set the PageCreator to return your page, don't use panels. Second you need to set a callbackhandler for the windowclose event. There you must update your combo. Maurice On Nov 7, 2007 12:09 PM, serban.balamaci <[EMAIL PROTECTED]> wrote: > > Hello! > I have the following problem. I have a parent page, that opens a popup > through a PageLink. > The popup window is a window in which new records can be added, but i need a > combo in the parent page to reflect and contain also the new choice added in > the popup. > > 1. Reloading the whole parent page at popup close link pressed i would take > as the last resolve because the user may have introduced data in the > controls that would get lost in the reloading process. I could get around > this by adding a submit behaviour to the link and save in session the values > inserted till that moment and rehidrate the model with values from the > session instead of the database, and so obtain the state that the page was > in before the popup was opened, but i'm wondering if there is not a cleaner > solution for this. > > 2. I also tried(didn't think this would work:) but had to try) to pass the > combo to the popup page and tried to update through the pressing of an > ajaxlink the combo. It said it could not find the markup id for the > combo(expected since it tried in the popup and not in the parent) so i guess > that this approach could be made valid if the ajax callback would be > directed at the parent page instead of the popup - i do not know how to do > this. > > 3. Another option I am considering is calling a self.opener.function in > which i would have javascript code for the ajax update of the combo in the > parent. What code that is doing the ajax update i still do not know where to > find-> maybe on the onselectionchange behaviour would be the way to find > out, or if it breaks something in the way wicket is working. > > Anybody has any pointers of what would be the nice way to implement, > comments, or other ways to tackle the problem? > > Thanks. > -- > View this message in context: > http://www.nabble.com/Popup-parent-comunication-tf4763947.html#a13625027 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > 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: Multiple tags on a single base page?
thanks!
I think people become accustomed to how they used wicket up to now.
Therefore, they don't see this "weakness" as they worked around it countless
times. However, "never change a running system" isn't an argument to me ...
and it wasn't to the first guy who said that the wheel should be round ;)
Chris Colman wrote:
>
>> Hey Chris, I would need some lobbying here! ;)
>>
>> -- stefan
>
> You're doing a great job Stefan - especially now I see that you've
> implemented it - excellent job!
>
> Are we both seeing something here that other people can't see? It wouldn't
> be the first time in my life I was in that position - only years later do
> people go "oh yeah" what a great idea...
>
> I can only guess that most people haven't actually discovered the power
> and reuse facilitated by the child/extend tag because if they had then
> it's not such a great stretch to see the power of supporting more than one
> extendible section - we're just arguing over multiplicity, not the
> extendible section concept itself.
>
> Most of the "panels can do that" arguments, in my mind, disparage the
> existing child/extend concept as much as they do the proposed support for
> multiple single extendible sections.
>
> The, "I can do that with panels" argument sounds like C programmers back
> in the early 90s saying, "I don't need C++ I can do everything in C with
> function pointers". Well you probably could but by embarking on a short
> learning curve you could be 1000x times more productive.
>
> Someone asked for another explanation of the difference so I'll do that
> again in a following post.
>
>>
>>
>>
>> Chris Colman wrote:
>> >
>> >> Wouldn't this essentially be the same as using > >> id="header"/> and using WebMarkupContainers on the java side?
>> >> I.e.:
>> >>
>> >> Base
>> >>
>> >
>> > Structural markup goes here (see below for explanation of this)
>> >
>> >>
>> >
>> > More structural markup goes here
>> >
>> >>
>> >
>> > And again more structural markup goes here too
>> >
>> >>
>> >> PumpsBase
>> >> -
>> >>
>> >> A header for all pages to do with pumps
>> >>
>> >>
>> >> Note: no body implemented here - deferred until a more specialized
>> >> class/markups: WaterPumpsBase and OilPumpsBase
>> >>
>> >> WaterPumpBase
>> >> -
>> >> Note: no header implemented here - the general PumpsBase one suffices
>> >> for all pumps pages
>> >>
>> >>
>> >> A body discussing water pumps
>> >>
>> >>
>> > ...
>> >
>> >>
>> >> On the java side you'd have to addOrReplace(new
>> >> WebMarkupContainer("header")) but it's essentially the same. Or am I
>> >> missing some point?
>> >
>> > This is indeed very different. If it were not so then the wicket
>> > developers would never have conceived the need for the current
>> > child/extend tag pair.
>> >
>> > The power of inheritance at the markup level is that you can define
>> > markup once in a base markup file that is inherited by all derived
>> > markup files. The derived markup files only supply sections that
>> provide
>> > "specialized sections of markup - the rest, at render time, comes from
>> > the base class.
>> >
>> > You would typically use components (panels) within these specialized
>> > sections but using the panel mechanism as you describe above as a
>> > replacement for the powerful markup inheritance feature of wicket is
>> not
>> > possible.
>> >
>> > In the panel example you give you must still provide all of the
>> > structural markup surrounding your panel tags in EVERY page's markup in
>> > your system and if you decide to make a system wide change of this
>> > structural markup you must edit every page's markup to reflect that
>> > change. In an OO markup world you provide the structural markup in as
>> > many pages as you want but at render time the only structural markup
>> > used is that provided in the base base - which is very powerful because
>> > you can make system wide changes by modifying only that single base
>> > page's markup. Wicket is the first framework I've seen that allows
>> > proper OO reuse concepts at the markup level.
>> >
>> > This is what many people wicket developers with an OO wiring in their
>> > brain are doing right now with the existing child/extend feature - and
>> > to great benefit.
>> >
>> > This new feature, or extension of the exiting feature, allows more than
>> > one section of markup to be "specialized" by derived (extended) markups
>> > whereas currently wicket only supports the deferred
>> > definition/implementation of a single markup section in any page. In
>> > other words we want to make a powerful feature even more powerful.
>> >
>> > It must be stated again (for the benefit of those who have just
>> recently
>> > joined this thread) that supporting multiple sections whose
>> > implementation can be deferred to extended markups does not equate to
>> > multiple inheritance (a big "no no" in the OO world). Multiple
>> > overridden sections is analogous to the support of
RE: Multiple tags on a single base page?
> Korbinian Bachl wrote: > > you missed solution3: > > the real-wicket-way(tm) for multiple content-places in a tied page-area: > > Whaaa, I seriously hope this is not the real-wicket-way! My brain hurts! > > A framework is supposed to make things easy and readable! The code below > is just way too complicated to achieve something that should be easy... > > Preferably when doing simple stuff like this, I don't want to be > confronted with things like rendering (and adding render hooks), or with > keeping extra state about components being or not being initalized. Also > I don't want to have to copy this boiler plate for every time I want to > place some kind of component "hole" in a base page! > Well said! I agree wholeheartedly. I suppose the reason I'm so passionate about this new multiple child/extends support is that it helps preserve simplicity for the wicket developer instead of making our more complex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
hi stefan, > And if somebody really needs 5 child areas, something else might be even > messier than the page's constructor. I rather think that 2, 3 or in rare > cases even 4 ids could make sense. i must disagree - i have a basepage which defines the default layout on a project, i.e. header, top-nav-container (imprint etc), navigation, content-left/-right/main, footer - this makes 7 panels which are added on the way down to the resulting page... but i don't use abstract methods for this, for it can get messy (as stated in other comments). regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
>From the Java-side, it isn't visible, whether a component will be placed in whatever html part. So you add all components in the constructor, yes. However, it's as messy as adding 5 components is right now ... they will just be added at different places. And if somebody really needs 5 child areas, something else might be even messier than the page's constructor. I rather think that 2, 3 or in rare cases even 4 ids could make sense. Is that what you meant? -- stefan Johan Compagner wrote: > > no not the merging of markup. > but inside the constructor of the child/sub page. > Where do you make all the root components of all the child parts? > you will add that to the page itself right? > > I just say that then it could be a bit messy when you have 5 child area's > > johan > > > > On 11/7/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> >> hi johan, >> >> >> Johan Compagner wrote: >> > >> > 1 thing that does bother me a bit (but maybe i have to do a deeper look >> > into >> > the patch) how do you separate >> > the components in the constructor of the sub page.. i guess you just >> add >> > all >> > the components over all the child fragments >> > in the page itself. That's not a nice separation... That can lead to >> big >> a >> > big mess.. Because what component belong to what child part. " >> > >> >> I don't get what you mean here. However, my implementation is closely >> related to Juergen's MergedMarkup.java (and admittedly partially copied) >> and >> does the same. >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631363 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: Multiple tags on a single base page?
hi johan, Johan Compagner wrote: > > 1 thing that does bother me a bit (but maybe i have to do a deeper look > into > the patch) how do you separate > the components in the constructor of the sub page.. i guess you just add > all > the components over all the child fragments > in the page itself. That's not a nice separation... That can lead to big a > big mess.. Because what component belong to what child part. " > I don't get what you mean here. However, my implementation is closely related to Juergen's MergedMarkup.java (and admittedly partially copied) and does the same. - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154 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: 1.2 or 1.3 beta 4 ?
On Nov 7, 2007 12:37 PM, Christofer Jennings <[EMAIL PROTECTED]> wrote: > I want to pitch Wicket for a new project at work. Is 1.3 beta 4 stable > enough? Is there a ballpark idea of when 1.3 final will be out? ... I > know that's a dumb question on an open source project but I guy can > dream. We're currently trying to get the first RC out (see dev list), so that means we are pushing towards final rather than adding more features etc. 1.3 is much improved compared to 1.2, so I think you should definitively go for 1.3 Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple tags on a single base page?
> and in extending classes you can easily do this:
>
> protected void initialize() {
>
> addToAnything(new AnyPanel("id"));
> addToAnything(new AnyPanel2("id2"));
> }
So now you're proposing the Java code is defining the layout of
components? That's what the markup's job is I thought.
What I, and probably many others, like about wicket is that the Java
code is just a "slave" to the markup - not the other way around. The
graphic designers are free to control where everything goes in markup
and so long as I have implemented a Java class for each panel that they
want to use then everything just works. They can rearrange the whole
look and layout of the side without me touching my Java code.
Your solution is starting to look very much like the Echo2 solution -
where layout is controlled entirely in Java.
Also: Does your addToAnything method assume a regular, repeating pattern
- like panels in a column or row? What if the panels I want to
specialize in derived pages are not laid out in a grid or array
structure: eg., a sub header that spans the entire page width plus a
side menu on the left plus a body section in the middle - all separately
implemented at various levels in the page hierarchy but with the
structural HTML that lays them out specified in one place in the base
page?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Popup parent comunication
I cannot use the modal windows. They are plain popups. I do not know if there is a difference beetween modal windows that have a content a panel or a page, but i need to have tabbed pannels(which are links) inside the popup and by using a modal page with a panel content when i press on another tab(a link), i get the message that "This action requires to navigate away from this page and the modal window will close" and after pressing it does close the modal window. I am currently trying the 3rd option, i think i can write the javascript for the ajax request. I will post the solution if i get it working. Mr Mean wrote: > > Are you using the ModalWindow? in that case you need to set the > PageCreator to return your page, don't use panels. Second you need to > set a callbackhandler for the windowclose event. There you must update > your combo. > > Maurice > > On Nov 7, 2007 12:09 PM, serban.balamaci <[EMAIL PROTECTED]> wrote: >> >> Hello! >> I have the following problem. I have a parent page, that opens a popup >> through a PageLink. >> The popup window is a window in which new records can be added, but i >> need a >> combo in the parent page to reflect and contain also the new choice added >> in >> the popup. >> >> 1. Reloading the whole parent page at popup close link pressed i would >> take >> as the last resolve because the user may have introduced data in the >> controls that would get lost in the reloading process. I could get around >> this by adding a submit behaviour to the link and save in session the >> values >> inserted till that moment and rehidrate the model with values from the >> session instead of the database, and so obtain the state that the page >> was >> in before the popup was opened, but i'm wondering if there is not a >> cleaner >> solution for this. >> >> 2. I also tried(didn't think this would work:) but had to try) to pass >> the >> combo to the popup page and tried to update through the pressing of an >> ajaxlink the combo. It said it could not find the markup id for the >> combo(expected since it tried in the popup and not in the parent) so i >> guess >> that this approach could be made valid if the ajax callback would be >> directed at the parent page instead of the popup - i do not know how to >> do >> this. >> >> 3. Another option I am considering is calling a self.opener.function in >> which i would have javascript code for the ajax update of the combo in >> the >> parent. What code that is doing the ajax update i still do not know where >> to >> find-> maybe on the onselectionchange behaviour would be the way to find >> out, or if it breaks something in the way wicket is working. >> >> Anybody has any pointers of what would be the nice way to implement, >> comments, or other ways to tackle the problem? >> >> Thanks. >> -- >> View this message in context: >> http://www.nabble.com/Popup-parent-comunication-tf4763947.html#a13625027 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> 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] > > > -- View this message in context: http://www.nabble.com/Popup-parent-comunication-tf4763947.html#a13626466 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: Problem with wicket authentication
Ok, I had just a look at the Swarm home page, and didn't go further, but promise I will look at it deeper, now I know it's simple. Swarm is designed to be plain and simple. In short this is what you need to do: 1 implement Principal (i could see about a reasonable default implementation , but my guess is you want to store this in a database anyway and i am not sure i want a dependency on jpa) 2 create policy files 3 implement WaspApplication (by extending SwarmApplication) Off the top of my hat, that is al you need to get the default running. Off course if you want something special you need something more, but where don't you need to do that. But if you feel we could improve on some areas, let me know. Maurice On Nov 6, 2007 10:35 PM, <[EMAIL PROTECTED]> wrote: > I wished to try the basic Wicket authentication because it looked plain > simple (and simplicity and fewer code is my mantra!) > I had seen the Swarm one, but it didn't look as straightforward. Maybe I > will give it a try if I can't go with the standard one. > > Regards, > Hugues > - Regards, Hugues -- View this message in context: http://www.nabble.com/Problem-with-wicket-authentication-tf4751663.html#a13635200 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: gmap2 and map creation
Jan Stette schrieb: I'm pretty sure I'm using the latest version: sorry I was just to tired yesterday look into that any deeper. I just committed a patch. Could you check if it suits your needs? Also could you check if the codechange in the ManyPanel is asking for the same as your code? Good night, Martin $ svn info Path: . URL: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-gmap2 Repository Root: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff Repository UUID: ef7698a4-5110-0410-9fc6-c7eb3693863f Revision: 3219 Node Kind: directory Schedule: normal Last Changed Author: funkattack Last Changed Rev: 3149 Last Changed Date: 2007-10-23 21:44:10 +0100 (Tue, 23 Oct 2007) Actually, that stack trace might have been misleading as I had been playing around with the code in GMap2... Here's a stack trace with the original version: Caused by: org.apache.wicket.WicketRuntimeException: This component is not (yet) coupled to a page. It has to be able to find the page it is supposed to operate in before you can call this method (Component#getMarkupId) at org.apache.wicket.Component.getMarkupId(Component.java:1201) at wicket.contrib.gmap.GMap2.getJSinvoke(GMap2.java:399) at wicket.contrib.gmap.GMap2.getJSsetCenter(GMap2.java:424) at wicket.contrib.gmap.GMap2.setCenter(GMap2.java:353) Jan On 06/11/2007, Martin Funk <[EMAIL PROTECTED]> wrote: Hi Jan, to operate in before you can call this method (Component#getMarkupId) at org.apache.wicket.Component.getMarkupId(Component.java:1201) at wicket.contrib.gmap.GMap2.getJSinvoke(GMap2.java:399) at wicket.contrib.gmap.GMap2.getJSsetZoom(GMap2.java:424) at wicket.contrib.gmap.GMap2.setZoom(GMap2.java:353) (This is with Wicket 1.3 beta 4, and the head of gmap2) Looking at the line numbers I'd ask, are you sure you are running the latest wicket-contrib-gmap2? like svn info Pfad: . URL: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-gmap2 Basis des Projektarchivs: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff UUID des Projektarchivs: ef7698a4-5110-0410-9fc6-c7eb3693863f Revision: 3219 Knotentyp: Verzeichnis Plan: normal Letzter Autor: funkattack Letzte geänderte Rev: 3149 Letztes Änderungsdatum: 2007-10-23 22:44:10 +0200 (Di, 23 Okt 2007) Also the description sounds like something we might have covered in the one of the last updates. Have fun, Martin - 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: Multiple tags on a single base page?
> ok tell me with 2 examples what is soo different about having 2 panels (or > fragments) > in a page and implement that in a sub page or having 2 wicket childs in a > page and implement those in a sub page. Ok, here we go... (well one example at least - it's getting late here ;) ) I'm not sure what angle you're coming from: there seems to be two things to argue about here: 1) the value of markup inheritance as facilitated by the ability to "override" or "defer implementation" of a single section of a base page, via the existing child/extends tags, to a sub page's markup. 2) the multiplicity of overridden sections (ie., allowing more than one) The first point is easy to argue for - if you don't have an tag in a page then that page, when rendered, uses ALL of the markup of that page - it does not merge any markup with a base page. In other words, you need to set up the structural markup around your panels etc., identically in every page if you want to have the same look and feel across your whole site. If you change the structure of your page you need to edit EVERY page... nasty! If you do have a tag in your base page and in sub pages then wicket works in a much more clever and powerful way: the whole of the base page markup, except for the section is "merged in" when rendering the sub page. In other words - all subpages share the same structural markup surrounding the section. This is very powerful and it's exactly the same concept that's been used in OO languages for the last 20 years. The sub pages have a chance to "specialize" the appearance of the page, albeit (currently) in only one section. No OO language limits the number of methods that can be "specialized" in a sub class to just one method - it would be very restrictive, would make no sense and there would be no logic in such a limitation. In the same way there is no logical reason why the number of "specialized" sections in sub pages in wicket should be limited to just one. What Stefan has brilliantly done is created a wicket patch that does away with this unnecessary limitation of only one specialized section per page. So if you already use and see the value in the child/extend take then support for Multiple "specialized" sections per page is just a simple multiplicity argument. Do you ever find yourself creating more than one overridden method in a Java class? Well then you'll probably feel the urge to do the same in markup now once you grasp the power of markup inheritance. For those wanting an example I'm not a graphic artist, but a developer, so naturally I used a software modeling/coding tool to illustrate an example of how such multiplicity is useful: The picture is a .vcm model (3kb zipped) and is downloaded from: http://www.stepaheadsoftware.com/products/javelin/examples/multipleSpeci alizedSections.zip You can use freeware version (1.3MB) of the Javelin modeling tool to view it, which can be downloaded from: http://www.stepaheadsoftware.com/products/javelin/javelind.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied page-area:
eg: html:
...
Place to put anything
...
java:
public abstract MyPage extends AnyPageExtendingWicketsWebPage {
private boolean initialized = false;
private final RepeatingView anything;
MyPage() {
super();
anything = new RepeatingView("anything");
add(anything);
}
/**
* Abstract place to add content to the containers
*/
protected abstract void initialize();
@Override
protected void onBeforeRender() {
super.onBeforeRender();
if(!initialized) {
initialize();
initialized = true;
}
}
/**
* Adds the content-Component c to Column A
* (the smaller one on the left)
*
* @return
*/
public void addToAnthing(Component c) {
c.setRenderBodyOnly(true);
getAnything().addOrReplace(c);
}
public RepeatingView getAything() {
return anything;
}
}
and in extending classes you can easily do this:
protected void initialize() {
addToAnything(new AnyPanel("id"));
addToAnything(new AnyPanel2("id2"));
}
etc.
this is maximum flexible, fast implemented, beeing checked by the IDE
and nice OO behaviour as it allows you to chain this over several
levels, plus it aids you when it comes to security-limitations as you
have a logic hirarchy where you can use each step for more restricted
access-rules
e.g: BasePage -> SecureBasePage -> HighlySecuredBasePage -> MyPage
if you then need a panel manipulating other areas this is easily done by:
e.g:
(MyPage getPage()).getAnything().doWhatYouWantToDo(WhatYouWant)
(you could also make this final thing abstract and then only override it
in the page you place it in wich gives even more control and makes it
reusable over projects)
and this is sth. that happens more often than you expect IMHO
plus the biggest advancement: the HTML tied to the classes stays clean
and is not poluted with some fancy tags (wich is the bigest plague in
the Javaworld IMHO... i never understood how they could invent things
like JSP or JSF that are worse to even PHP code in a page)
Best
Korbinian
Stefan Fußenegger schrieb:
Hi Mats, let me try to explain what Chris and I see here that others don't -
may it be there or not ;)
You can of course do everything with panels that could be done with multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you wouldn't need markup inheritance
at all! The proposed change is just an extension of exactly this markup
inheritance concept (that everybody loves) to make it even more powerful
than it already is.
I was quite new to wicket (which I still am) and came across a situation
where I wanted to use two abstract sections: one for a sub-navigation that
was common for several pages in a section and one for the actual content.
For me, as a wicket newbie, it would have been most natural to use markup
inheritance to solve this problem. Using abstract methods, while being a
nice solution (workaround?), didn't come to my mind at once, nor did I find
it somewhere in the docs.
imho, there are two possible solution to this problem:
1. promote using abstract methods for this in the docs as the wicket-way of
doing it
2. extend the current markup inheritance mechanism (which I tried to do with
my patch/prototype)
-- stefan
Mats Norén-2 wrote:
On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
Hmm...I'm interested in seeing the difference as well. I would love to
get it but right now I don't.
Chris Colman wrote:
"This new feature, or extension of the exiting feature, allows more than
one section of markup to be "specialized" by derived (extended) markups
whereas currently wicket only supports the deferred
definition/implementation of a single markup section in any page. In
other words we want to make a powerful feature even more powerful."
Is the above statement really true considering that by adding abstract
methods to your page you defer the creation of the markup in just the
same way as the new proposed solution?
BasePage.java
public BasePage() {
addAbstract1("abstractId1");
addAbstract2("abstractId2);
}
public abstract addAbstract1(String abstractId1);
public abstract addAbstract2(String abstractId2);
A little typo here..I meant:
public BasePage() {
add(addAbstract1("abstractId1"));
add(addAbstract2("abstractId2));
}
public abstract Component addAbstract1(String abstractId1);
public abstract Component addAbstract2(String abstractId2);
/Mats
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-
Re: Multiple tags on a single base page?
Yes! see: https://issues.apache.org/jira/browse/WICKET-1134 -- stefan Scott Swank wrote: > > I can see how and tags could be > a nice enhancement to the current and > tags. Do you have a working, or mostly working, patch? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13634545 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: Why dioes this error occur?
I am using wicket-1.2.6. Unfortunately it is not possible for me to upgrade to a newer version. > Hi salmas, > > On 07 November 2007, 7:05:26 PM, salmas wrote: > s> Every once in awhile if I am clicking around for awhile in the UI of my > s> application I get the following error. What causes this? > > s> java.lang.NullPointerException > s> at > s> > wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveListenerInterfaceTarget(DefaultRequestTargetResolverStrategy.java:295) > > What version of Wicket are you using? > > -- > /Gwyn > > > - > 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: 1.2 or 1.3 beta 4 ?
Martijn Dashorst wrote: As for 1.2 or 1.3.. .I suggest 1.3. It is running on a couple of production systems already [...] LOL. ;-) Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2 or 1.3 beta 4 ?
sounds good and congrats... Gerolf On Nov 7, 2007 9:58 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > On 11/7/07, Gerolf Seitz <[EMAIL PROTECTED]> wrote: > > On Nov 7, 2007 9:40 PM, Martijn Dashorst <[EMAIL PROTECTED]> > wrote: > > > As for 1.2 or 1.3.. .I suggest 1.3. It is running on a couple of > > > production systems already, and it has some great new stuff I couldn't > > > live without anymore. > > > > is the upgrade of vocus to 1.3 done? last thing i heard was that johan > is > > working on that. > > It is not deployed yet, but the conversion stuff is done. Now we need > to test it. But the biggest issue is business... A part of the system > is developed on a separate branch, needs to be merged in our current > production branch, and HEAD is our 1.3 branch. So we are properly > screwed in this regard. > > Fortunately I have other projects I could build with 1.3, and that was > really nice. And the book is also 1.3 based, which makes me biased :) > > Martijn > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.0-beta4 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Multiple tags on a single base page?
On Nov 7, 2007 11:19 AM, Scott Swank <[EMAIL PROTECTED]> wrote: > I can see how and tags could be > a nice enhancement to the current and > tags. Do you have a working, or mostly working, patch? What I think we should do with this is make it an option. It would be turned off by default, requiring users to an extra one or two lines of configuration to turn this on (we've done this before), and let it prove itself. Sounds to me like everyone would be happy. WDYT? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
Chris Colman schrieb: The beauty of the multiple extend/child idea is that it's not a completely new concept we're talking about here - it's merely an issue of supporting n>1 instead of arbitrarily fixing n=1 like it is now. 1 Question: Who dominates Who and Why? If you extend 1 class by class you create specialisations that dominate each other, but here you just mess together some classes - so why should which class dominate? If we manipulate a headertag? If we have same namespace? If we have different securitylevels? Wich class is responsible for all this? Why? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tree table colors
Hello everyone, Been using wicket for the past month on a prototype I am working on. Great framework !!! Have a question regarding the tree table, I am using it to display sub-totals and would like to give sub-total row a different color. How can I accomplish this? Thanks Gene
Re: Popup parent comunication
if your modal dialog contains ajax tabs it should work, but all your user interaction from withing the dialog must be ajax. Maurice On Nov 7, 2007 1:50 PM, serban.balamaci <[EMAIL PROTECTED]> wrote: > > I cannot use the modal windows. > They are plain popups. I do not know if there is a difference beetween modal > windows that have a content a panel or a page, but i need to have tabbed > pannels(which are links) inside the popup and by using a modal page with a > panel content when i press on another tab(a link), i get the message that > "This action requires to navigate away from this page and the modal window > will close" and after pressing it does close the modal window. > > I am currently trying the 3rd option, i think i can write the javascript for > the ajax request. > I will post the solution if i get it working. > > > > Mr Mean wrote: > > > > Are you using the ModalWindow? in that case you need to set the > > PageCreator to return your page, don't use panels. Second you need to > > set a callbackhandler for the windowclose event. There you must update > > your combo. > > > > Maurice > > > > On Nov 7, 2007 12:09 PM, serban.balamaci <[EMAIL PROTECTED]> wrote: > >> > >> Hello! > >> I have the following problem. I have a parent page, that opens a popup > >> through a PageLink. > >> The popup window is a window in which new records can be added, but i > >> need a > >> combo in the parent page to reflect and contain also the new choice added > >> in > >> the popup. > >> > >> 1. Reloading the whole parent page at popup close link pressed i would > >> take > >> as the last resolve because the user may have introduced data in the > >> controls that would get lost in the reloading process. I could get around > >> this by adding a submit behaviour to the link and save in session the > >> values > >> inserted till that moment and rehidrate the model with values from the > >> session instead of the database, and so obtain the state that the page > >> was > >> in before the popup was opened, but i'm wondering if there is not a > >> cleaner > >> solution for this. > >> > >> 2. I also tried(didn't think this would work:) but had to try) to pass > >> the > >> combo to the popup page and tried to update through the pressing of an > >> ajaxlink the combo. It said it could not find the markup id for the > >> combo(expected since it tried in the popup and not in the parent) so i > >> guess > >> that this approach could be made valid if the ajax callback would be > >> directed at the parent page instead of the popup - i do not know how to > >> do > >> this. > >> > >> 3. Another option I am considering is calling a self.opener.function in > >> which i would have javascript code for the ajax update of the combo in > >> the > >> parent. What code that is doing the ajax update i still do not know where > >> to > >> find-> maybe on the onselectionchange behaviour would be the way to find > >> out, or if it breaks something in the way wicket is working. > >> > >> Anybody has any pointers of what would be the nice way to implement, > >> comments, or other ways to tackle the problem? > >> > >> Thanks. > >> -- > >> View this message in context: > >> http://www.nabble.com/Popup-parent-comunication-tf4763947.html#a13625027 > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> - > >> 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] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Popup-parent-comunication-tf4763947.html#a13626466 > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > 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: 1.2 or 1.3 beta 4 ?
On 11/7/07, Gerolf Seitz <[EMAIL PROTECTED]> wrote: > On Nov 7, 2007 9:40 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > As for 1.2 or 1.3.. .I suggest 1.3. It is running on a couple of > > production systems already, and it has some great new stuff I couldn't > > live without anymore. > > is the upgrade of vocus to 1.3 done? last thing i heard was that johan is > working on that. It is not deployed yet, but the conversion stuff is done. Now we need to test it. But the biggest issue is business... A part of the system is developed on a separate branch, needs to be merged in our current production branch, and HEAD is our 1.3 branch. So we are properly screwed in this regard. Fortunately I have other projects I could build with 1.3, and that was really nice. And the book is also 1.3 based, which makes me biased :) Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.2 or 1.3 beta 4 ?
I want to pitch Wicket for a new project at work. Is 1.3 beta 4 stable enough? Is there a ballpark idea of when 1.3 final will be out? ... I know that's a dumb question on an open source project but I guy can dream. Thanks! ,boz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2 or 1.3 beta 4 ?
On Nov 7, 2007 9:40 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > See the development list... We're working hard. > > As for 1.2 or 1.3.. .I suggest 1.3. It is running on a couple of > production systems already, and it has some great new stuff I couldn't > live without anymore. > is the upgrade of vocus to 1.3 done? last thing i heard was that johan is working on that. just curious... Gerolf > > Martijn > > On 11/7/07, Christofer Jennings <[EMAIL PROTECTED]> wrote: > > I want to pitch Wicket for a new project at work. Is 1.3 beta 4 stable > > enough? Is there a ballpark idea of when 1.3 final will be out? ... I > > know that's a dumb question on an open source project but I guy can > > dream. > > > > Thanks! > > ,boz > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.0-beta4 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: 1.2 or 1.3 beta 4 ?
See the development list... We're working hard. As for 1.2 or 1.3.. .I suggest 1.3. It is running on a couple of production systems already, and it has some great new stuff I couldn't live without anymore. Martijn On 11/7/07, Christofer Jennings <[EMAIL PROTECTED]> wrote: > I want to pitch Wicket for a new project at work. Is 1.3 beta 4 stable > enough? Is there a ballpark idea of when 1.3 final will be out? ... I > know that's a dumb question on an open source project but I guy can > dream. > > Thanks! > ,boz > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
John Krasnay wrote:
You've just illustrated one of the major problems with the
panel-from-a-subclass approach: it's easy to get it wrong. In your
example, addAbstract1 and addAbstract2 will be called in a class whose
constructor has not yet been called. Consider:
public DerivedPage extends BasePage {
private String name;
public DerivedPage(String name) {
super();
this.name = name;
}
public abstract addAbstract1(String abstractId1) {
add(new NamePanel(abstractId1, name));
}
}
This code is broken, since you're constructing NamePanel before name has
been initialized. Someone later in this thread shows a better way to do
this, by calling the overridable methods from onBeforeRender. But this
is also tricky; because onBeforeRender can be called multiple times you
must maintain a flag to ensure you only add your panels once.
In fact, almost all official sources consider this an antipattern (e.g.
Effective Java #15), and specifically state that you should never call
overridable methods from a constructor at all. So either the method
called from the constructor should be private or it should be final.
I wonder what the "official" Wicket policy is on this? Careful
documentation?
Regards,
Sebastiaan
Given these subtle problems with this approach, I admit I'm warming to
the multiple extend/child idea.
jk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Multiple tags on a single base page?
On Nov 7, 2007 5:13 PM, John Krasnay <[EMAIL PROTECTED]> wrote:
> You've just illustrated one of the major problems with the
> panel-from-a-subclass approach: it's easy to get it wrong. In your
> example, addAbstract1 and addAbstract2 will be called in a class whose
> constructor has not yet been called. Consider:
>
> public DerivedPage extends BasePage {
>
> private String name;
>
> public DerivedPage(String name) {
> super();
> this.name = name;
> }
>
> public abstract addAbstract1(String abstractId1) {
> add(new NamePanel(abstractId1, name));
> }
> }
>
> This code is broken, since you're constructing NamePanel before name has
> been initialized. Someone later in this thread shows a better way to do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times you
> must maintain a flag to ensure you only add your panels once.
>
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.
I stand corrected! :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
let me weigh in with my thoughts on this.
a big problem with markup inheritance is the possibility of id collissions
for example
class basepage extends webpage {
public basepage() {
add(new label("label"));
}
}
class concretepage extends basepage {
public concretepage() {
add(new label("label"));
}
}
basepage:
concretepage:
now what you are proposing here makes this collission possibility
significantly higher because essentially i CANNOT even have something
like this:
even though to me it looks like the nasting of foo1 and foo2 are
seperate so i should be able to have a direct child with the same id
in bothbut i cannot.
a lot of people are saying that this can be implemented with panels,
and that is true. but actually implementing this with fragments will
make it look very similar to this new strategy and does not have the
id collission problem, because components ARE nested in two different
containers:
class basepage extends webpage {
Fragment templateFoo1(String id) { return new emptyfragment(id); }
Fragment templateFoo2(String id) { return new emptyfragment(id); }
}
thoughts?
-igor
On 11/2/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>
> Hi folks,
>
> I just stumbled on a situation where it would be useful to have two or more
> tags in a base page. Just consider a layout that consists
> of the usual footer, header, navigation, and content parts. But now, the
> content should be arranged in two columns, e.g. two different s.
>
> To give a short example, the BasePage.html cloud look like this
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> And the Child.html markup would look like this:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wouldn't that be a desirable feature? I tried to run the above example
> expecting to get an exception. The second wicket:child/wicket:extend pair
> was happily ignored though.
>
> Best regards, Stefan
> --
> View this message in context:
> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> 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: Multiple tags on a single base page?
> public DerivedPage extends BasePage {
>
> private String name;
>
> public DerivedPage(String name) {
> super();
> this.name = name;
> }
>
> public abstract addAbstract1(String abstractId1) {
> add(new NamePanel(abstractId1, name));
> }
> }
>
> This code is broken, since you're constructing NamePanel before name
has
> been initialized. Someone later in this thread shows a better way to
do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times
you
> must maintain a flag to ensure you only add your panels once.
>
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.
Good to hear!! Multiple abstract/implements (child/extends) lets us
avoid the ugly plumbing code suggested in previous posts as an
alternative. I'd rather extend an elegant existing feature with
multiplicity than have to add low level plumbing code to my apps that
assumes a knowledge of the lifecycle methods (eg., onBeforeRender -
never needed to override that method for anything else before now) and
requires me to hook in to the lifecycle at various obscure places like
suggested. I think this goes against the wicket's simplicity motto way
more than supporting multiple child/extends sections does.
The beauty of the multiple extend/child idea is that it's not a
completely new concept we're talking about here - it's merely an issue
of supporting n>1 instead of arbitrarily fixing n=1 like it is now.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
read my previous reply more carefuly, instead of
abstract Component getTemplateOne(String id);
you can simply do: Component getTemplateOne(String id) { return new
EmptyPanel(id); }
now you have a "non-required" override of any part of markup's template...
-igor
On Nov 7, 2007 10:51 AM, Chris Colman <[EMAIL PROTECTED]> wrote:
> > a lot of people are saying that this can be implemented with panels,
> > and that is true. but actually implementing this with fragments will
> > make it look very similar to this new strategy and does not have the
> > id collission problem, because components ARE nested in two different
> > containers:
>
> I've never used fragments but I just read up on them...
>
> I may be wrong but it looks as if you have to define all possible
> fragments that might appear in a page to that page. It doesn't seem to
> follow the natural, organic flow of markup inheritance where a base page
> can be enhanced by substituting base a page section with markup defined
> in derived/extended pages - that only happens with the child/extends
> feature from my understanding.
>
>
> -
> 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: Multiple tags on a single base page?
On Nov 7, 2007 11:22 AM, Chris Colman <[EMAIL PROTECTED]> wrote: > > > How can it get messy when it's not yet possible to do in wicket? > > > > i believe it has been shown multiple times already that it CAN be done > > with vanilla wicket... > > I didn't like the look of any of those 'coded' solutions. i dont like the look of a lot of code in wicket, but that is not a valid criteria > They were not from the coding elegance book I've read. that is extremely subjective, so once again - not a valid criteria. you have just as many people saying they prefer it... > They also mean I'm starting to > arrange, layout and compose my pages in Java instead of markup (meaning > my graphic designers lose control). not at all. in java you simply declare the areas that can be extended. this is no different then a page adding components that are meant to be in some wicket:implements tag. > The abilty to control layout completely at the markup level instead of > the Java level is why I moved to Wicket from another framework in the > first place and I guess a lot of others have too. like i said, you dont lose that at all > The division of > responsibility in Wicket is something not achieved by any other > framework I have used which is great because I don't think I'm going to > be able to teach my graphic designers Java any time soon. i can argue that now your graphics designer needs to know about the "hierarchy" of pages in order to know which wicekt:implement areas are available to them in some page, so... > > I also wouldn't classify as "vanilla" that alternative, workaround using > low level plumbing code that hooks into the lifecycle methods. there is nothing low-level about onbeforerender() - its not called internalOnBeforeRender() is it? > It's more > like a honeycomb chocolate fudge, banana sundae, with 1" thick caramel > sauce sprinkled with 100s and 1000s ;) - it sounds great on the menu > but after you've finished it you're left wondering if you made the right > decision. i have implemented code like that and was not left wondering at all, but maybe thats just me -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple tags on a single base page?
this cannot be an option. it always has to be enabled. if i write a component that uses this and someone drops it into application where this is disabled what should happen? -igor On Nov 7, 2007 1:05 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > On Nov 7, 2007 11:19 AM, Scott Swank <[EMAIL PROTECTED]> wrote: > > I can see how and tags could be > > a nice enhancement to the current and > > tags. Do you have a working, or mostly working, patch? > > What I think we should do with this is make it an option. It would be > turned off by default, requiring users to an extra one or two lines of > configuration to turn this on (we've done this before), and let it > prove itself. Sounds to me like everyone would be happy. > > WDYT? > > Eelco > > > - > 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: Multiple tags on a single base page?
or you can just use a factory that lets you create transparent borders :) -igor On Nov 7, 2007 12:05 PM, Chris Colman <[EMAIL PROTECTED]> wrote: > Presumably the coded work arounds that don't rely on child/extends mean > that the structural markup of each page is used instead of just that of > the base page - and that would spell maintenance issues. Without using > child/extend then ALL the structural markup in each page is used for > each render - NOTHING is pulled from the base page markup (kind of makes > me wonder why we need base page markup if not using child/extend - but > that's another topic!). > > A change of layout structure would mean changing all page markups - yuck > - or do you guys not care about your graphics designers - "arh, that's > their problem if they want to do a site wide change!" > > I think the fundamental thing that most people are missing is that each > component must be well formed XHTML, complete and self contained. If it > starts a (or ) then it must also end it. Divs (and tables) > are the basic structural elements of markup. > > One component can't be the start of a structural span of markup, the > next few components content sections for that span and then the last > component ends the structural span - that is not possible because each > component must be well formed and complete. > > So this infers that structural markup typically is stored in page markup > and "wraps" markup that inserts various self contained components. > > Now here's the thing: without using child/extends then that structural > markup must be carefully defined in EVERY page markup because wicket > does not do the funky inheritance merging when you don't use the > child/extends tag. > > So if you want to change a border in between two components you must > change it in EVERY page markup. That would suck. > > Alternatively, if you do use the current child/extend you end up having > to bang multiple components into the overridden section which means that > you also bang in the border that exists between them - so now the border > markup is duplicated many times. > > > - > 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: Why dioes this error occur?
I tried disabling the button during the event and while this was easy enough to implement it did not help. My page contains a table which has panels in different cells. I swap these panels in and out depending on wether the user is in 'edit' mode or 'submit' mode and also according to where they are in the workflow. I noticed that the method of PropertyColumn which I am overriding populateItem(Item item, String componentId, IModel model) completes, as does the event handling code at the button press so I am not sure what is breaking down. It's easy to reproduce this error. All I have to do is to click a button which is present in one of the panels rapidly, at every click I do toggle the name of the button from "edit" to "save" so I don't know if this has something to do with it. I do need this problem resolved because this is not acceptable for a production application. I would really appreciate any ideas that you have. salmas wrote: > > > I am using wicket-1.2.6. Unfortunately it is not possible for me to > upgrade to a newer version. > >> Hi salmas, >> >> On 07 November 2007, 7:05:26 PM, salmas wrote: >> s> Every once in awhile if I am clicking around for awhile in the UI of >> my >> s> application I get the following error. What causes this? >> >> s> java.lang.NullPointerException >> s> at >> s> >> wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveListenerInterfaceTarget(DefaultRequestTargetResolverStrategy.java:295) >> >> What version of Wicket are you using? >> >> -- >> /Gwyn >> >> >> - >> 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] > > > -- View this message in context: http://www.nabble.com/Why-dioes-this-error-occur--tf4766684.html#a13636661 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ResourceReference with locale and style, for CSSs
Hi all,
I'm having trouble with localized and styled CSSs.
Everything works alright with HTML. For example, wicket finds
MyPage_mystyle.html instead of MyPage.html if i've called
session.setStyle("mystyle"). But for CSS i can't get it working.
i've tried different approaches like:
// inside the page constructor
add(HeaderContributor.forCss(new ResourceReference(MyPage.class,
"style.css")));
// inside renderHead
cResponse.getHeaderResponse().renderCSSReference(new
ResourceReference(MyPage.class, "style.css"));
None of this worked for me. However, it works if I call the full
constructor of ResourceReference:
new ResourceReference(MyPage.class, "style.css", getLocale(), getStyle())
But i'm not supposed to do that, because then the Locale and Style are
forced, and i want this only if the file is present. I know some
ResourceStreamLocator should be involved in the process, but i don't know
how. I see in the ResourceReference javadoc that the framework should be
calling the setStyle() method, but i debugged it and it doesn't happen.
What am i doing wrong?
Thanks in advance,
German
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
UrlCodingStrategy with unmatched key/value pairs
I am having a problem with the UrlCodingStrategy. I'm currently extending BookmarkablePageRequestTargetUrlCodingStrategy. The problem is that the app is decoding some of the characters in the url before I get the url in the decodeParameters method. For example, the url once encoded looks like this: /linkframe/item/187822/site/Wine/sitetopic/Food%2FDrink where the params are item=187822, site=Wine, and sitetopic=Food%2FDrink When the decode method in BookmarkablePageRequestTargetUrlCodingStrategy calls requestParameters.getPath() the url looks like this: /linkframe/item/187822/site/Wine/sitetopic/Food/Drink This is causing a problem because the app thinks the URL fragment has unmatched key/value pairs. I cannot seem to find where/why the %2F is getting resolved to a /. Can someone help me with this? I need to keep this from happening. It's causing null pointers all over the place. -- View this message in context: http://www.nabble.com/UrlCodingStrategy-with-unmatched-key-value-pairs-tf4767649.html#a13636974 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: Multiple tags on a single base page?
Eelco Hillenius wrote: On Nov 7, 2007 1:32 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: this cannot be an option. it always has to be enabled. if i write a component that uses this and someone drops it into application where this is disabled what should happen? You wouldn't write such a component for general purposes obviously. Of course it can be optional (it might have to be a whole separate tag rather than building on wicket:extend); it's up to the users after that. Sorry, but I'm with Igor on this one. What's the point of making you jump through hoops to enable this? - It'll require thought to not break reusable components, as Igor says. - It's extra config- and API-width we don't need; we'll have to deprecate the method to turn it on once it becomes "standard", mention it in migration docs for 1.5(?), support it on the mailing list, etc. etc. - If we add it, it looks like lots of people will use it. We're then stuck with it - it's a change that would never get backed out unless someone comes up with a vastly better way of doing all this such that it's completely obsolete. Don't give users more knobs to twiddle than you absolutely must. ;-) FWIW, I've thought of a nice use-case for this: BasePage.html: ConcretePage.html: Here is my help text, complete with a table and other things that would be a pain to put in a properties file and use i18n for. Here is the main body of the page. I guess it'd be nice to be able to do this purely in markup without having to make a help Fragment, or add an EmptyPanel if there is no help. This issue/question is raised frequently enough on the mailing list that I think we should just implement it. I dunno about putting it in for 1.3, though. Probably a 1.4 feature? ;-) Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UrlCodingStrategy with unmatched key/value pairs
what are you doing then in your own BookmarkablePageRequestTargetUrlCodingStrategy? who generates that url? and what is that Food%2FDrink? Should that be 1 param? And has the param a /? which version do you use? On 11/7/07, green804 <[EMAIL PROTECTED]> wrote: > > > I am having a problem with the UrlCodingStrategy. I'm currently extending > BookmarkablePageRequestTargetUrlCodingStrategy. The problem is that the > app > is decoding some of the characters in the url before I get the url in the > decodeParameters method. > > For example, the url once encoded looks like this: > > /linkframe/item/187822/site/Wine/sitetopic/Food%2FDrink > > where the params are item=187822, site=Wine, and sitetopic=Food%2FDrink > > When the decode method in BookmarkablePageRequestTargetUrlCodingStrategy > calls requestParameters.getPath() the url looks like this: > > /linkframe/item/187822/site/Wine/sitetopic/Food/Drink > > This is causing a problem because the app thinks the URL fragment has > unmatched key/value pairs. I cannot seem to find where/why the %2F is > getting resolved to a /. Can someone help me with this? I need to keep > this from happening. It's causing null pointers all over the place. > -- > View this message in context: > http://www.nabble.com/UrlCodingStrategy-with-unmatched-key-value-pairs-tf4767649.html#a13636974 > 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: Multiple tags on a single base page?
On Nov 7, 2007 1:39 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > You wouldn't write such a component for general purposes obviously. ok, that right there i really really dont like. define "general purpose"? so now we have features in wicket that are guaranteed to work and others that arent? this is going to turn the framework into an abysmal pile of crap. why should i only use some "safe" subset when writing a component im planning on reusing across projects? -igor Of > course it can be optional (it might have to be a whole separate tag > rather than building on wicket:extend); it's up to the users after > that. > > > Eelco > > - > 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: WicketNotSerializableException withi FileUpload
what is the full stack of the exception?
because who does have that field?
Streams should always be transient because those can't be serialized
whats the wicket version?
johan
On 11/6/07, James Perry <[EMAIL PROTECTED]> wrote:
>
> Hello fellow Wicket users,
>
> I am getting a
> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
> Unable to serialize class:
> org.apache.wicket.util.io.DeferredFileOutputStream exception when I
> added a file upload feature to my AddProductForm.
>
> My form is serialiazable yet I don't which of its child components are
> not serializable. Can anyone shed any light on this?
>
> Cheers,
> James.
>
> Here is my Page class:
>
> public class AddProductPage extends AdminPage {
>
>private static final long serialVersionUID = 1L;
>
>@SpringBean(name="adminService")
>private AdminService adminService;
>
>public AddProductPage(Product product) {
>MenuBorder border = new MenuBorder("libBorder");
>border.add(new FeedbackPanel("feedback"));
>border.add(new AddProductForm("productForm", product));
>add(border);
>}
>
>private final class AddProductForm extends Form {
>
>private static final long serialVersionUID = 1L;
>
>private FileUploadField fileUploadField;
>
>public AddProductForm(String id, Product product) {
>super(id, new CompoundPropertyModel(product));
>setMultiPart(true);
>add(new RequiredTextField("name"));
>add(new RequiredTextArea("description"));
>add(new RequiredTextField("sellValue",
> BigDecimal.class));
>add(new RequiredTextField("units", Long.class));
>add(new CheckBox("onSell"));
>add(new DropDownChoice("category",
> catalogService.getCategories()));
>add(new DropDownChoice("manufacturer",
> catalogService.getManufacturers()));
>add(fileUploadField = new
> FileUploadField("fileInput", new
> Model(fileUploadField)));
>setMaxSize(Bytes.megabytes(100));
>}
>
>@Override
>protected void onSubmit() {
>final FileUpload upload =
> fileUploadField.getFileUpload();
>if (upload != null)
>System.out.println("File is not empty! Whoo
> hooo!");
>else
>System.out.println("File is empty! Whoo
> hooo!");
>fileUploadField.detachModels();
>/**Product product = (Product) getModelObject();
>product.setEntryDate(new Timestamp(
> System.currentTimeMillis()));
>product.setImageURL("uploads/");
>System.out.println(product.getCategory());
>adminService.saveProduct(product);
>setResponsePage(ViewProductsPage.class);**/
>}
>
>}
>
> }
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Attempted summary of multiple thread
Hi, Since the thread on multiple support is insanely long I'm going to try make a clear and concise summary of what has been proposed and what the arguments for and against were. Bear with me. :-) 1. What is proposed? Currently Wicket supports *merging* of markup on a base page with markup on an a page which extends it through the and tags. When the child page is rendered, the markup of the base page is used, but the ... part is *replaced* by what is between the ... part in the child page (thus *merging* the two). Currently only 1 child part is allowed in the base page and only 1 extend part in allowed in the child page. The request is to allow multiple such parts to be replaced during the murge. To know which part must be replaced with which, it is proposed that the above tags have an id attribute to match them pair by pair. As Chris Colman aptly put it: the *only* thing being requested is to remove the limitation of n=1 pairs and to allow n>1 pairs of parts to replaced during the merge. NOTE: This has been called markup inheritance (as suggested by the names child and extend), but in the thread has also been compared to abstract methods and implementing them. I recommend not using any analogies to confuse matters and just seeing it for what it is, a relaxation of the constraint that n=1 during merge. NOTE 2: A patch by Stefan Fussenegger which implements this feature request has been submitted to the Wicket JIRA. In his patch he used different tags names, but the behavior for the case n=1 is exactly that of the current feature. 2. Is even necessary? No, it's a convenience feature. You can get the same effect by making a BasePage.html, BasePage.java, ChildPage.java, ChildPanel.java and ChildPanel.html, and using an abstract method or onBeforeRender (see the thread). If you don't like child/extend, you don't have to use it. 3. Arguments *for* the change. It is (very) convenient (same reason as for the current child/extend) and does not change how current Wicket applications work (i.e., it is 100% backward compatible). Only when you *add* an extra identifier attribute and put in multiple child/extends pairs, are you using the new feature. If you don't like it, you don't have to use it. 4. Arguments *against* the change. I saw only a few arguments against the change: a) It can already be done using - wicket panels/fragments + abstract methods - wicket panels/fragments + onBeginRender Apart from the obvious problems with the above methods (calling an overridable method from the constructor or extra IMHO non-intuitive boilerplate code), I do not see how this is an argument against just *removing an arbitrary restriction* on . b) No more extra tags! We already have enough tags in Wicket! In principle, no extra tags required; there is *no* collision with the current and tags. But if it is done with other tags (I would suggest deprecating child/extend in the next version of wicket then), you don't have to use these extra tags. c) It creates a mess: all the components contained in any of the extend parts are added to the child page in the constructor: this can cause name collisions and a huge number of components to be added, which is bad. But I do not see the difference between this and any other normal page where you use components. A bunch of them are added to the page itself, and another bunch are separated into components. It is up to the developer to choose how to do this. A (real world) demonstration of the two different *use cases*, namely the reason why you would use a panel for one and a wicket/child for another, can be seen on the following page I recently built: http://www.denherdervarga.com/programma On the left there is a menu, in the center the content, on the right some context information for the page. The center (the content) is a clear use case of the current child/extend. The left is a panel, implemented with an abstract method getMenu(String id) on the base class. The MainMenu panel is reused across pages, and can change (in the admin section of the site the getMenu() method is overriden to return a completely different AdminMenu). The right is currently a with an abstract method on the base page. *But this a case where I would have preferred another child/extend.* The fact that the content is on the right is *PURE LAYOUT*. If I had chosen another layout where it was at the bottom of the content, it would have been *in* the content part. I would have had to add all the top level components to the page in the constructor, and I would have had to make sure that no wicket:id collisions occurred, *IN EXACTLY THE SAME WAY* as with multiple child/extends. Futhermore, there is no point in making a panel out of it, because it is specific to this page, and I'll *never* reuse it. Finally, in this (specific) case there is not even a wicket component in it, so if there would have been mu
Re: UrlCodingStrategy with unmatched key/value pairs
We are using 1.2.6 right now. The Food%2FDrink is one param. That param does have a /. Unfortunately, I can't change the param. I'm overriding the decodeParameters to handle the case with mismatched key/value pairs, but it's kind of a hack because I have to know which params might have a /. It's not a very generic solution. I'm hoping to track down where the decode is happening in the first place and override that instead. Johan Compagner wrote: > > what are you doing then in your own > BookmarkablePageRequestTargetUrlCodingStrategy? > > who generates that url? and what is that Food%2FDrink? Should that be 1 > param? And has the param a /? > > which version do you use? > > > On 11/7/07, green804 <[EMAIL PROTECTED]> wrote: >> >> >> I am having a problem with the UrlCodingStrategy. I'm currently >> extending >> BookmarkablePageRequestTargetUrlCodingStrategy. The problem is that the >> app >> is decoding some of the characters in the url before I get the url in the >> decodeParameters method. >> >> For example, the url once encoded looks like this: >> >> /linkframe/item/187822/site/Wine/sitetopic/Food%2FDrink >> >> where the params are item=187822, site=Wine, and sitetopic=Food%2FDrink >> >> When the decode method in BookmarkablePageRequestTargetUrlCodingStrategy >> calls requestParameters.getPath() the url looks like this: >> >> /linkframe/item/187822/site/Wine/sitetopic/Food/Drink >> >> This is causing a problem because the app thinks the URL fragment has >> unmatched key/value pairs. I cannot seem to find where/why the %2F is >> getting resolved to a /. Can someone help me with this? I need to keep >> this from happening. It's causing null pointers all over the place. >> -- >> View this message in context: >> http://www.nabble.com/UrlCodingStrategy-with-unmatched-key-value-pairs-tf4767649.html#a13636974 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/UrlCodingStrategy-with-unmatched-key-value-pairs-tf4767649.html#a13637200 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
