Re: Start a panel, border, or page with an XML declaration?
2009/10/4 David Chang david_q_zh...@yahoo.com: Phil, Thanks very much for your reply. By XML declaration, you mean something like: ?xml version=1.0 encoding=UTF-8 ? Correct? I found this piece and it may be interesting to all: That's right. http://learningtheworld.eu/2008/farewell-xml-declaration/ Well, it might make sense to skip the xml declaration when the output is being pushed straight the user agent (as with JSP, PHP etc), but with Wicket you require a full parsing of the xhtml data on the server side, so I would go with the best practice approach and keep the declaration. Wicket is much more able to transform xhtml than other frameworks, so the arguments aren't really the same. I prefer to include it in my source, and then have Wicket strip it out at the last moment - at least when I'm forced to be IE6 compatible I am interested in this solution. Could you please share with us the detailed how-to? There's no particular secret, just call this.getMarkupSettings().setStripXmlDeclarationFromOutput(true); in your Application.init() method. Regards. --- On Sun, 10/4/09, Phil Housley undeconstruc...@gmail.com wrote: From: Phil Housley undeconstruc...@gmail.com Subject: Re: Start a panel, border, or page with an XML declaration? To: users@wicket.apache.org Date: Sunday, October 4, 2009, 6:59 AM 2009/10/4 David Chang david_q_zh...@yahoo.com: Hello, I am reading Wicket in Action. The Tip on page 291 says it is good practice to start your panels and borders (possibly your pages) with an XML declaration to force Wicket to work with them using the proper encoding. Does this mean that starting a panel, border, or page with something such as the following: -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en head meta http-equiv=content-type content=text/html; charset=utf-8 / ... /head -- Actually, the xml declaration is the one starting ?xml, which includes your encoding as soon as possible in the file, before any actual content. Adding the doctype is also good practice, as it makes sure wicket/the browser/anything else that reads the file understands it exactly as you wrote it, but is a separate issue. is better than with: -- html head ... /head -- If yes, why do all the examples of the WIA book start simply with htmlhead.../head? To save space I assume. Thanks for your help! One final thing to note is that IE6 will screw up any page with an ?xml declaration. I prefer to include it in my source, and then have Wicket strip it out at the last moment - at least when I'm forced to be IE6 compatible. -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: how to map 2 html files to 1 class?
2009/10/5 Alex Rass a...@itbsllc.com: Standardizing footers across the site. So I will have a dozen pages which are bare content + footer from a common file/db. I don't want to have THAT many useless classes. If I do - wicket is a failure. It sounds as though you don't actually want to use any Wicket features for the content of any of these pages, so I don't think you actually want to create pages for them at all. Instead, I would have a general content page, and then interpret the rest of the URL as an argument. I can't remember which type of mount you need, but you would basically interpret something like: /content/home /content/index /content/something as all being the same page, with a single parameter. Then in the page class you just print out some raw HTML content for the entire middle bit of the page. There are various ways to do that, and you have a free choice if really all you want to do is write straight to the response. -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Monday, October 05, 2009 6:27 PM To: users@wicket.apache.org Subject: Re: how to map 2 html files to 1 class? What are you handling there ? ** Martin 2009/10/6 Alex Rass a...@itbsllc.com: PageA.html PageB.html PageC.html Think about it this way: PageA.html = Privacy Page PageB.html = SiteMap Page. I want to handle them both in same java class file cause hardly anything is going on there. -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Monday, October 05, 2009 6:08 PM To: users@wicket.apache.org Subject: Re: how to map 2 html files to 1 class? PageHandler.java, that handles all 3. mountBookmarkablePage(/PageA.html, PageHandler.class); mountBookmarkablePage(/PageB.html, PageHandler.class); mountBookmarkablePage(/PageC.html, PageHandler.class); This is a bit confusing, you ar giving different aliases to the same page. Is that what you want or you really want different html files also..`? ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Start a panel, border, or page with an XML declaration?
2009/10/4 David Chang david_q_zh...@yahoo.com: Hello, I am reading Wicket in Action. The Tip on page 291 says it is good practice to start your panels and borders (possibly your pages) with an XML declaration to force Wicket to work with them using the proper encoding. Does this mean that starting a panel, border, or page with something such as the following: -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en head meta http-equiv=content-type content=text/html; charset=utf-8 / ... /head -- Actually, the xml declaration is the one starting ?xml, which includes your encoding as soon as possible in the file, before any actual content. Adding the doctype is also good practice, as it makes sure wicket/the browser/anything else that reads the file understands it exactly as you wrote it, but is a separate issue. is better than with: -- html head ... /head -- If yes, why do all the examples of the WIA book start simply with htmlhead.../head? To save space I assume. Thanks for your help! One final thing to note is that IE6 will screw up any page with an ?xml declaration. I prefer to include it in my source, and then have Wicket strip it out at the last moment - at least when I'm forced to be IE6 compatible. -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Complicated workflows
2009/9/30 Igor Vaynberg igor.vaynb...@gmail.com:
there is really no point in having your tasks be components. why not simply
repeatingview rv=..
for (task t:tasks) {
if (t.hasUIComponent()) {
rv.add(t.getUIComponent());
}
}
-igor
Although only one task panel is ever drawn at the time, that is
broadly similar to how I have it set up at the moment. If a task is
also a panel, it can elect to have itself displayed, at which point it
will be embedded in the page and no stack processing will happen until
the panel says it is complete. Any other type of task simply doesn't
have the option to display, although it may spawn a panel task, which
may ask to be displayed, and so on.
The issue is that business logic should really always be in non-UI
tasks for things I have in mind, which lack things like easily being
able to call this.error(...). I believe you are right about not
forcing the issue, so I'm currently thinking I will have to step up
the infrastructure to add things like error reporting. Fortunately I
can just delegate to Wicket pretty quickly, so shouldn't be too much
extra code.
Phil.
On Tue, Sep 29, 2009 at 2:11 PM, Phil Housley undeconstruc...@gmail.com
wrote:
Hello list,
I'm currently working on some ideas for building apps with fairly
complex workflows. My aim is to find a nice pattern/framework for
building apps where each unit of work involves many panels, several
forms, lots of decisions and so on. In particular I'm aiming at apps
where you need to be very confident about exactly what is happening,
so very strict control of actions, being careful of multiple
renderings of a page each trying to change the server data, and so on.
Also, I'm wondering about some options for declarative building of
workflows out of existing tasks.
My current design involves running from a special page, which
maintains a stack of tasks. One type of task is a Workflow, which can
be configured to automatically spawn subtasks as required, based on
the result of previous tasks. Another type of task is based on a
panel, and is able to cause itself to be rendered. The stack
processor makes sure that each task is invoked at the right time, that
a task can render if it is at the top of the stack, that only the top
of the stack can be invoked from a form and so on.
This is working ok for some silly demo cases, but there are various
issues. For example, any task that is not also a component cannot
access dependency injection, or set error messages and so on. I'm not
sure how to get around this at the moment, as I don't want to force
every task to be a component, when many will likely have no cause to
ever be rendered.
So, the reason I'm posting is to ask mainly two things:
1) Is this of interest to anyone else? All the code is my own, so
I'll open source it if there seems to be some future in it.
2) If so, does anyone have any comments on my current design? Clearly
there are problems with it, but should I carry on trying to find ways
to work around them, or does the whole thing sounds like so much
crack?
Thanks,
--
Phil Housley
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Complicated workflows
2009/9/30 Randy S. randypo...@gmail.com: Have you thought about using Spring Web Flow for this? I'm not a SWF expert, but it sounds like something well-tailored to your needs. For example, a flow can have steps that don't have UIs. Our group at work is looking into Wicket SWF integration. I have a seen a few comments on the web from folks like Peter Thomas who conclude that you don't need to use SWF with Wicket. We need to externalize the flow of some applications so we have discussed shallow integration (where, for example, a button.onClick explicitly calls SWF to determine what to do next), as well as deep(er) integration (perhaps at the RequestCycleProcessor. At the moment, we are leaning toward the shallow/lightweight integration which gives lots of flexibility to each application to respond to a flow's response in different ways (show a new page, update components via Ajax, redirect to another URL, etc.). In case anyone is interested, reasons we need to externalize flow on some apps are things like: Complex business rules, business unit authoring of flow (via a controlled UI), and delegation to a business process manager layer. Actually, I hadn't realised that WebFlow wasn't limited to Spring MVC. Looking at it now, I am doing something fairly similar, so I probably ought to take a longer look... The reasons I started on this thing with code rather than going totally declarative is that my current experience is that there will be sufficient corner cases to make it necessary to regularly subclass actions or panels for a particular instance. Where that isn't required, I was thinking that a Spring context file would provide a nice declarative way of configuring everything, with prototype scope beans etc being well fitted to creating tasks. Despite all that, I don't particularly want a hard dependency on anything other than Wicket, so plain Java first, other things hopefully on top. Phil On Tue, Sep 29, 2009 at 4:11 PM, Phil Housley undeconstruc...@gmail.comwrote: Hello list, I'm currently working on some ideas for building apps with fairly complex workflows. My aim is to find a nice pattern/framework for building apps where each unit of work involves many panels, several forms, lots of decisions and so on. In particular I'm aiming at apps where you need to be very confident about exactly what is happening, so very strict control of actions, being careful of multiple renderings of a page each trying to change the server data, and so on. Also, I'm wondering about some options for declarative building of workflows out of existing tasks. My current design involves running from a special page, which maintains a stack of tasks. One type of task is a Workflow, which can be configured to automatically spawn subtasks as required, based on the result of previous tasks. Another type of task is based on a panel, and is able to cause itself to be rendered. The stack processor makes sure that each task is invoked at the right time, that a task can render if it is at the top of the stack, that only the top of the stack can be invoked from a form and so on. This is working ok for some silly demo cases, but there are various issues. For example, any task that is not also a component cannot access dependency injection, or set error messages and so on. I'm not sure how to get around this at the moment, as I don't want to force every task to be a component, when many will likely have no cause to ever be rendered. So, the reason I'm posting is to ask mainly two things: 1) Is this of interest to anyone else? All the code is my own, so I'll open source it if there seems to be some future in it. 2) If so, does anyone have any comments on my current design? Clearly there are problems with it, but should I carry on trying to find ways to work around them, or does the whole thing sounds like so much crack? Thanks, -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Selectively ignoring required fields
I'm bringing up my old thread here, as I found something that works
well enough, and it might help someone to have it in the list
archive.)
2009/9/15 Pedro Santos pedros...@gmail.com:
On the other hand, maybe that whole criteria panel is deselected, in
which case I want to be able to stop the whole thing from doing any
validation at all, so it won't even look at whether the check box is
checked.
disable panel don't work on that case?
Just overriding isEnabled didn't do the trick by itself, but I found a
rather nasty little hack. The issue is that the individual panels
need to always be enabled for rendering, but only selectively enabled
at processing. Also, the decision about which panel to enable is
based on incoming data, which isn't always ready when needed. A
solution is to have each panel check whether it is enabled, by calling
up to the parent panel. The parent does this:
public boolean isItMyTurn(Criteria panel) {
if (this.rendering) {
return true;
} else {
this.radios.inputChanged();
int index = Integer.parseInt(this.radios.getRawInput());
Criteria active = this.panels.get(index);
if (active == panel) {
return true;
}
}
return false;
}
Where rendering is set in before and after render methods, and the
radio buttons are partially processed out of sequence to get the input
when its needed.
I don't know how safe this is, but it seems to work.
Thanks everyone.
On Tue, Sep 15, 2009 at 11:10 AM, Phil Housley
undeconstruc...@gmail.comwrote:
2009/9/15 Bas Gooren b...@iswd.nl:
The fact of the matter is that you will need extra logic _somewhere_.
It's a
matter of personal preference where you put it (overriden components,
ajax,
override form methods, ...).
If what you're trying to accomplish is difficult given a certain set of
tools, my experience is that it's good to rethink the problem.
On the one hand you want isolation (components can have logic to say if
they
are required), and on the other hand you want to break outside of this
isolation (form needs to control required flag on components). Having
this
logic in two different places is error-prone (at least from my
experience).
So why not have a single point in your code where you deal with the
required
flags of these components?
Bas
A good point, but I don't think it exactly applies in this case. What
I really want is for each component to know whether it is required
within a very small context. For example, a might have a criteria
panel (one of the sub-parts of the searcher) set out as follows:
[x] must be a foo called [_]
In which case, the sub panel will be in total charge of whether the
text field is required.
On the other hand, maybe that whole criteria panel is deselected, in
which case I want to be able to stop the whole thing from doing any
validation at all, so it won't even look at whether the check box is
checked.
What I am thinking currently is to sadly discard the built in
validation, and have each criteria panel report its errors manually
when asked to by the parent to pass on its generated set of criteria
(a map basically), which it has built out of its input. I don't like
it at all, as it lets bad data get too far into the system, but I
think it will solve the immediate problem.
Phil.
- Original Message - From: Phil Housley
undeconstruc...@gmail.com
To: users@wicket.apache.org
Sent: Tuesday, September 15, 2009 3:37 PM
Subject: Re: Selectively ignoring required fields
Several interesting ideas, but they all seem to involve more invasive
changes than I really want to make - either changing component classes
or changing values of components at process time, which would be hard
to undo (and maybe not possible, as some components already have logic
to say if they are required.)
From hunting through the code, what would be about perfect would be to
override org.apache.wicket.markup.html.form.Form#validateComponents(),
but unfortunately that is final. Even if I were to copy some of the
code into my form class, there are some private methods of Form that I
would need to call.
Has anyone perhaps had a similar issue somewhere else?
Thanks again,
Phil.
2009/9/15 Bas Gooren b...@iswd.nl:
Phil,
The way we deal with this is by using an ajax behavior on radiobuttons,
and
update the required flag on dependant fields from there.
Another way (without ajax) could be to update the required flag on the
form
components on submit, prior to validation.
E.g. by overriding Form.process() (or Form.validate(), since this is
related
to validation).
E.g. something like
Form form = new Form( id, ... ) {
protected void validate
Complicated workflows
Hello list, I'm currently working on some ideas for building apps with fairly complex workflows. My aim is to find a nice pattern/framework for building apps where each unit of work involves many panels, several forms, lots of decisions and so on. In particular I'm aiming at apps where you need to be very confident about exactly what is happening, so very strict control of actions, being careful of multiple renderings of a page each trying to change the server data, and so on. Also, I'm wondering about some options for declarative building of workflows out of existing tasks. My current design involves running from a special page, which maintains a stack of tasks. One type of task is a Workflow, which can be configured to automatically spawn subtasks as required, based on the result of previous tasks. Another type of task is based on a panel, and is able to cause itself to be rendered. The stack processor makes sure that each task is invoked at the right time, that a task can render if it is at the top of the stack, that only the top of the stack can be invoked from a form and so on. This is working ok for some silly demo cases, but there are various issues. For example, any task that is not also a component cannot access dependency injection, or set error messages and so on. I'm not sure how to get around this at the moment, as I don't want to force every task to be a component, when many will likely have no cause to ever be rendered. So, the reason I'm posting is to ask mainly two things: 1) Is this of interest to anyone else? All the code is my own, so I'll open source it if there seems to be some future in it. 2) If so, does anyone have any comments on my current design? Clearly there are problems with it, but should I carry on trying to find ways to work around them, or does the whole thing sounds like so much crack? Thanks, -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Preventing Copy Pasting URL's In Same Browser Session
2009/9/29 Carlo Camerino carlo.camer...@gmail.com: Hi everyone, We have this requirement in which we cannot allow the customer to copy paste the url that's appearing in the address bar into the same browser. For example in a different tab or in a new window. This can easily be done in Wicket Framework since the url has a corresponding page attached to it. For example if i get http://localhost/wicket:interface=1 appearing in the address bar, I can open anew tab paste the url and I could get into the same page. The users don't want this behavior. Could I make it work in such a way that I copy http://localhost/wicket:inteface=1, when i try to copy and paste it, it will redirect me to an error page? This happens even after the user has already logged in. Really need help on this one. I've been playing with the ideas from http://day-to-day-stuff.blogspot.com/2008/10/wicket-extreme-consistent-urls.html for something of my own, which might fit the bill in a way. Following that you can convince wicket to serve up every instance of a mounted page from exactly the same URL. That means if you copy the url, you get a brand new instance of the page. You lose the ability to refresh, but if you are being strict on that sort of thing, I guess you will have a refresh button on the page when and only when it is appropriate. -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Complicated workflows
2009/9/29 Scott Swank scott.sw...@gmail.com: Phil, Would an event-centric approach simplify things? I'm thinking that you could then have multiple listeners for a given event and the various listeners would not have to be aware of one another. This might reduce the task/sub-task interactions. Adding errors, or refreshing components could be handled by various listeners as needed. I did consider that route, but one of the things I most want is to be able to embed one workflow in another, so I can reuse common tasks - hence the stack where a workflow is just like another task. Having listeners doesn't make much sense, I felt, when adding a new task/workflow to the stack temporarily hides everything underneath. Currently there really isn't much interaction between sibling tasks, when the current task says it is complete, another task is prepared, possibly showing a panel, or maybe just running and completing immediately. Events are simulated by having a task return a code, and the wiring says what transition follows each code. e.g. Task 1, on success - Task 2, on failure - Task X I've gone that route with reasonable luck. Of course I know precious little about your specific application... Really there is no specific application, I'm just trying to solve a general problem. The inspiration is my day job, for which I wrote a tiny little workflow engine, which basically just gives some help switching panels around. I'm not allowed to do a version 2 there though, so I'm doing it off my own back at home. Cheers, Scott On Tue, Sep 29, 2009 at 2:11 PM, Phil Housley undeconstruc...@gmail.com wrote: Hello list, I'm currently working on some ideas for building apps with fairly complex workflows. My aim is to find a nice pattern/framework for building apps where each unit of work involves many panels, several forms, lots of decisions and so on. In particular I'm aiming at apps where you need to be very confident about exactly what is happening, so very strict control of actions, being careful of multiple renderings of a page each trying to change the server data, and so on. Also, I'm wondering about some options for declarative building of workflows out of existing tasks. My current design involves running from a special page, which maintains a stack of tasks. One type of task is a Workflow, which can be configured to automatically spawn subtasks as required, based on the result of previous tasks. Another type of task is based on a panel, and is able to cause itself to be rendered. The stack processor makes sure that each task is invoked at the right time, that a task can render if it is at the top of the stack, that only the top of the stack can be invoked from a form and so on. This is working ok for some silly demo cases, but there are various issues. For example, any task that is not also a component cannot access dependency injection, or set error messages and so on. I'm not sure how to get around this at the moment, as I don't want to force every task to be a component, when many will likely have no cause to ever be rendered. So, the reason I'm posting is to ask mainly two things: 1) Is this of interest to anyone else? All the code is my own, so I'll open source it if there seems to be some future in it. 2) If so, does anyone have any comments on my current design? Clearly there are problems with it, but should I carry on trying to find ways to work around them, or does the whole thing sounds like so much crack? Thanks, -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Selectively ignoring required fields
Hello, I'm currently working on a search interface, where the required-ness of some fields depends on the value of some other. In particular, the form looks something like (+) search by X a: [_] b: [_] () search by Y ... () search by Z ... So the radio button selects a group of fields, in which any number may be required. Each group of options is its own panel, and basically independent. Is it possible for me to ignore protests from the fields in sections Y and Z, after reading the input from the radio button? Ideally I'd like to record the values from every field, and keep it around as raw input, but I don't want to know if it is missing or fails to convert/validate. Thanks for any help. -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Selectively ignoring required fields
2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com: You can override isRequired for any component. ** Martin Thanks, but I really don't want to have to make the individual fields context aware unless I have to. We have quite a few custom form controls, which are used both in searching and various other places, so it would be a lot of work to make them all respond to this particular use. A way to just prevent the required check/validation from the top would fit the bill better. 2009/9/15 Phil Housley undeconstruc...@gmail.com: Hello, I'm currently working on a search interface, where the required-ness of some fields depends on the value of some other. In particular, the form looks something like (+) search by X a: [_] b: [_] () search by Y ... () search by Z ... So the radio button selects a group of fields, in which any number may be required. Each group of options is its own panel, and basically independent. Is it possible for me to ignore protests from the fields in sections Y and Z, after reading the input from the radio button? Ideally I'd like to record the values from every field, and keep it around as raw input, but I don't want to know if it is missing or fails to convert/validate. Thanks for any help. -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Phil Housley - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Selectively ignoring required fields
Several interesting ideas, but they all seem to involve more invasive
changes than I really want to make - either changing component classes
or changing values of components at process time, which would be hard
to undo (and maybe not possible, as some components already have logic
to say if they are required.)
From hunting through the code, what would be about perfect would be to
override org.apache.wicket.markup.html.form.Form#validateComponents(),
but unfortunately that is final. Even if I were to copy some of the
code into my form class, there are some private methods of Form that I
would need to call.
Has anyone perhaps had a similar issue somewhere else?
Thanks again,
Phil.
2009/9/15 Bas Gooren b...@iswd.nl:
Phil,
The way we deal with this is by using an ajax behavior on radiobuttons, and
update the required flag on dependant fields from there.
Another way (without ajax) could be to update the required flag on the form
components on submit, prior to validation.
E.g. by overriding Form.process() (or Form.validate(), since this is related
to validation).
E.g. something like
Form form = new Form( id, ... ) {
protected void validate() {
// Update required flags on fields
// ...
// Call regular validation
super.validate();
}
}
Regards,
Bas
- Original Message - From: Phil Housley
undeconstruc...@gmail.com
To: users@wicket.apache.org
Sent: Tuesday, September 15, 2009 2:30 PM
Subject: Re: Selectively ignoring required fields
2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:
You can override isRequired for any component.
**
Martin
Thanks, but I really don't want to have to make the individual fields
context aware unless I have to. We have quite a few custom form
controls, which are used both in searching and various other places,
so it would be a lot of work to make them all respond to this
particular use. A way to just prevent the required check/validation
from the top would fit the bill better.
2009/9/15 Phil Housley undeconstruc...@gmail.com:
Hello,
I'm currently working on a search interface, where the required-ness
of some fields depends on the value of some other. In particular, the
form looks something like
(+) search by X
a: [_]
b: [_]
() search by Y
...
() search by Z
...
So the radio button selects a group of fields, in which any number may
be required. Each group of options is its own panel, and basically
independent. Is it possible for me to ignore protests from the fields
in sections Y and Z, after reading the input from the radio button?
Ideally I'd like to record the values from every field, and keep it
around as raw input, but I don't want to know if it is missing or
fails to convert/validate.
Thanks for any help.
--
Phil Housley
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Phil Housley
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Phil Housley
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Selectively ignoring required fields
2009/9/15 Bas Gooren b...@iswd.nl:
The fact of the matter is that you will need extra logic _somewhere_. It's a
matter of personal preference where you put it (overriden components, ajax,
override form methods, ...).
If what you're trying to accomplish is difficult given a certain set of
tools, my experience is that it's good to rethink the problem.
On the one hand you want isolation (components can have logic to say if they
are required), and on the other hand you want to break outside of this
isolation (form needs to control required flag on components). Having this
logic in two different places is error-prone (at least from my experience).
So why not have a single point in your code where you deal with the required
flags of these components?
Bas
A good point, but I don't think it exactly applies in this case. What
I really want is for each component to know whether it is required
within a very small context. For example, a might have a criteria
panel (one of the sub-parts of the searcher) set out as follows:
[x] must be a foo called [_]
In which case, the sub panel will be in total charge of whether the
text field is required.
On the other hand, maybe that whole criteria panel is deselected, in
which case I want to be able to stop the whole thing from doing any
validation at all, so it won't even look at whether the check box is
checked.
What I am thinking currently is to sadly discard the built in
validation, and have each criteria panel report its errors manually
when asked to by the parent to pass on its generated set of criteria
(a map basically), which it has built out of its input. I don't like
it at all, as it lets bad data get too far into the system, but I
think it will solve the immediate problem.
Phil.
- Original Message - From: Phil Housley
undeconstruc...@gmail.com
To: users@wicket.apache.org
Sent: Tuesday, September 15, 2009 3:37 PM
Subject: Re: Selectively ignoring required fields
Several interesting ideas, but they all seem to involve more invasive
changes than I really want to make - either changing component classes
or changing values of components at process time, which would be hard
to undo (and maybe not possible, as some components already have logic
to say if they are required.)
From hunting through the code, what would be about perfect would be to
override org.apache.wicket.markup.html.form.Form#validateComponents(),
but unfortunately that is final. Even if I were to copy some of the
code into my form class, there are some private methods of Form that I
would need to call.
Has anyone perhaps had a similar issue somewhere else?
Thanks again,
Phil.
2009/9/15 Bas Gooren b...@iswd.nl:
Phil,
The way we deal with this is by using an ajax behavior on radiobuttons,
and
update the required flag on dependant fields from there.
Another way (without ajax) could be to update the required flag on the
form
components on submit, prior to validation.
E.g. by overriding Form.process() (or Form.validate(), since this is
related
to validation).
E.g. something like
Form form = new Form( id, ... ) {
protected void validate() {
// Update required flags on fields
// ...
// Call regular validation
super.validate();
}
}
Regards,
Bas
- Original Message - From: Phil Housley
undeconstruc...@gmail.com
To: users@wicket.apache.org
Sent: Tuesday, September 15, 2009 2:30 PM
Subject: Re: Selectively ignoring required fields
2009/9/15 Martin Makundi martin.maku...@koodaripalvelut.com:
You can override isRequired for any component.
**
Martin
Thanks, but I really don't want to have to make the individual fields
context aware unless I have to. We have quite a few custom form
controls, which are used both in searching and various other places,
so it would be a lot of work to make them all respond to this
particular use. A way to just prevent the required check/validation
from the top would fit the bill better.
2009/9/15 Phil Housley undeconstruc...@gmail.com:
Hello,
I'm currently working on a search interface, where the required-ness
of some fields depends on the value of some other. In particular, the
form looks something like
(+) search by X
a: [_]
b: [_]
() search by Y
...
() search by Z
...
So the radio button selects a group of fields, in which any number may
be required. Each group of options is its own panel, and basically
independent. Is it possible for me to ignore protests from the fields
in sections Y and Z, after reading the input from the radio button?
Ideally I'd like to record the values from every field, and keep it
around as raw input, but I don't want to know if it is missing or
fails to convert/validate.
Thanks for any help.
--
Phil Housley
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
