I could do with some help once again...
We built our own forms in XPages. Forms are defined by a user in Notes, and they are used through XPages/web. We added several managed beans to get more grip on the data used by the page and controls that are on it. The whole thing is heavily nested, the form control can be used more than once on a page, repeat controls are used as well, and now I need to partially refresh a panel.
Some of the code:
<xp:panel id="ccAnyForm">
<xp:this.dataContexts>
<xp:dataContext var="formulaire">
<xp:this.value><![CDATA[#{javascript:compositeData.formName || compositeData.dataSource.getItemValueString("Formulaire")}]]></xp:this.value>
</xp:dataContext>
<xp:dataContext var="formdata">
<xp:this.value><![CDATA[#{javascript:PageData.getForm(formulaire, compositeData.dataSource)}]]></xp:this.value>
</xp:dataContext>
</xp:this.dataContexts>
<xp:panel id="aFormulaire${javascript:compositeData.name}">
<xe:switchFacet id="switchFacet1">
<xe:this.selectedFacet><![CDATA[#{javascript:formdata.isTabbed()? "tabbed": "flat"}]]></xe:this.selectedFacet>
PageData is a Java bean, and I lose formdata when doing a partial refresh. If I set partial execution mode in the EventHandler (data validation is disabled), I get the error that says formdata not found on the last line of the snippet. If I clear partial execution mode, I get nothing at all: no error, no Java error, no SSJS error, nothing.
It must be my lack of understanding the life-cycle of objects and variables, for I prbably have to use ValueBindings or so, but I don't know how.
Help...
I've seen dataContexts recalculate as null, particularly when dependent on other dataContexts. I think in Apply Request Values phase. When I had that I changed the code to only calculate in Render Response phase.
However, I don't think that work for you, because the Switch control will need the value before Render Response, and there's no easy way to get hold of which other phase is running.
The approach I'd take is to have a property in your bean (e.g. showTabbed) that holds which Switch facet to show. Call a bean method to set that property on page load. Then in your partial refresh, call the method again, checking whether the Formulaire field has changed to determine whether or not to call setShowTabbed(boolean) again. That will minimise the number of calls even more and should prevent the problem.
Related
My user requires any validation items (e.g. piece of data missing) to be displayed on screen, and not to be actually enforced (i.e. not to be checked to be totally valid) until further along in the process.
To accomplish this, on every save, I'll be checking for the presence of certain data. On initial object creation (of the object to be validated), I'm going to create a list of Validation items referring to specific fields (or their getters) as necessary. I will then be able to run through these items on each and every save, to check whether each item is "Valid" or not. At any point, I'll be able to display validation results to the user, as required.
Does this sound like a sensible approach? Am I missing a standardised way of approaching this task?
Usually validation is not done on save but on change. That simply means you have to attach change listeners to your fields, which then all execute your validation routine.
Listeners are only attached to the fields that are part of
validation.
Validation routine usually builds a list of errors/warnings which can be later presented in your UI
Also using JGoodies Validation will simplify your task. It is the best validation framework for Swing IMO
Its late and im tired, but this problem is bugging me like crazy.
I have a form. This form has some input fields that maps to a entity and will be persisted when submitted.
On the same page (but not a part of the form) I have an overview of this entity's children.
The struts2-Action has a method called edit() that will be run before the form is displayed. This method takes the provided id-parameter and retrieves the complete entity (including children) from the database.
So the form is then displayed nicely with children information.
However. When validation (serverside) has an error. The entity-object does no longer have children. All information (except what was in the form-fields itself) seems to have disappered.
What should i do to still see my children even after validation fails?
It's late and I'm tired too but off the top of my head:
I would have avoided the issue probably by using ajax (that is make the action into smaller parts, since one service seems to be unrelated to the other, that is displaying the children need not be tied to updating the entity).
But that is a lot of work and particularly so if you don't use ajax. What is really easy is implementing Validateable (or if you extend ActionSupport it already does that) and then adding/overriding the validate method. If you use xml for validation don't worry both are run.
Then create a setup method to populate the fields you need, and place it at the right location in the validate method (probably the first line). Since this will always run before execute, it will probably reduce the size of the execute method.
I'm helping to build a GWT application for a client and rewrote most of the stuff to work better, shorter code, faster, etc. However in all the GUI application I've worked on (not so many really) there comes a flexing point where you just have to put a lot of rules and move logic from the listeners to some common mediator. Then some times this could get an ugly mess so you whatever small think you need to do in the listener.
Let's take an example:
form with 10-20 fields
two exclusive radio control about half of the state of the other fields (enabling, validation, input limits)
three exclusive radio controls control again almost the same fields, but in a different way (affecting calculations, enabling); they are also controlled by the above
4 or so number fields are validated on the fly depending on the previous selections and some real-time data object; they can have upper/lower limits, be enabled/disabled
one drop-down box controls the next 6 or so controls - displaying/hiding them, modifying validators
some checkboxes (shown by the above combo) activate some input fields and also determine their validation algorithm
While everything is up an running, without known bugs, there are a few coding gotchas that really bother me:
code is spread among listeners and some mediator methods.
loading the form with some preset values presents its own challenges: like data objects that might be available or not, data objects that might alter their state and subsequent field behaviour
some fields are having a default value set and this should not be overwritten by automatic filling, but if the data objects are not there (yet) then they will need to be filled eventually when the later become available
form cannot be submitted if any of the fields are not validated
My approach:
identify which fields share a common afair and move code into one place
each radio group shares a single listener implementation between its radios
default form filling is deferred until the live data is available (as much as possible) and as a result it gets called multiple times
each action has a call to a common validator method
the validator runs through all the fields in the form, calls their validators (which highlight all errors) and returns a single boolean
each relevant keypress or mouse action, data change it gets deferred to be called after 250ms from the last call; this means first call just places the validator as a delayed action, subsequent calls reset the timer
Ok, it doesn't make any sense to dwelve into more details but I'm more upset about the fact that there is no clear separation between visual actions (enabling), data actions (setting form field values), field listeners, retrieving form values and live data listeners.
What would be a good approach/pattern (next time maybe) to make sure that MVC get separated and lends itself better to maintenance? I know this is not a typical question but I've read every documentation I could get my hands on and still did not find some helpful answer.
I'd move closer towards MVP than MVC. It's clearly the way Google intends to go, so adopting it will probably mean that you're able to go with the flow rather than fight the current.
How does this affect you? Well, I believe you should accept that a tidier implementation may involve more code: not the 'shorter code' you were hoping for. But, if it's logically structured, efficient code the Google compiler should be able to trim lots out in the compiler optimisation phase.
So, move as much of the logic as you can into the model layer. Test this thoroughly, and verify that the correct level of page reset/tidying happens (all of this can be done with plain JUnit, without any UI). Next, use your Presenter (Activity) to tie the View to the Model: handling the interactions, populating the fields, etc.
you can divide a Huge class in different classes bu dividing the GUI in different JPanels. All the panels are implemented in different classes extending JPanel. Guess that would help you.
Let's say I have five or more input computers that can affect whether a single drop down menu is displayed. The issue I am running into is that if the drop down menu is displayed once (thus setting the value in the backing bean through ajax) and the user then changes one of the affecting input components, then the backing bean value of the drop down menu is not getting reset when the drop down goes into hiding using the rendered property. For example:
<h:selectOneMenu id="sampleDropDown" required="false" immediate="true"
onchange="jsUpdateSampleDropDownValue()" value="#{backingBean.value}"
rendered="#{backingBean.shouldShowSampleDropDown}"
actionListener="#{backingBean.listener}" />
I understand that I have options here. I've debated whether I should add a generic ValueChangeListener (apply request values phase) or an EventHandler (render response phase) that would listen in on the values of the other inputs and make a decision on whether to clear the drop down menu value but this certainly is more work then just letting the rendered property make that decision.
We've seen dozens of the same type of issue on the project I'm currently on and I'd really like to hear from the experts on the best practice for handling this type of situation. In case it matters we are using custom ajax (not ajax4jsf) and jsf 1.1. Any help is appreciated.
The solution I came up with is to not try and reset the input component in the backing bean value of the renderered property.
I have a phase listener attached to the single page interface and am essentially passing request parameters in the javascript method (i.e. jsUpdateSampleDropDownValue()) so that business logic data can be loaded in the rendered response phase using the chain of responsibility pattern.
When a request parameter is passed (i.e. RESET_SAMPLE_DROP_DOWN) onchange that matches a corresponding event handler (i.e. ResetSampleDropDownEventHandler), I check a separate "constraint" class (see Hardcore Java book) that validates whether enough data is accumulated before either clearing the binding value or continuing with the request.
This allows the logic to be centralized yet be attached to multiple components. You may be asking why a single JSF ValueChangeListener was not attached to each component which would allow the same re-use. The reason for this is because our business logic takes place in the render response phase after the update model phase so it makes sence that any "reset" type methods occur after any "defaulting" of values.
I'm performing a validation task that takes a while and am spinning the validation process into a separate thread. I've got the progress bar side of things working, with PortableRenderer and a ViewScope allowing it to update the progress bar component.
However, I'm trying to redirect the user once the page either finishes or a error in validation occurs, without the need of user interaction.
I'm using AND new to icefaces2.0(beta 1) and JSF 2.0, so the answer might be right in front of me. Sorry if this is a pretty simple question.
Have ajax to execute this job rather than spawning a thread yourself.
Update as per the comments: well, that was a bit curt. But spawning a thread yourself inside a servletcontainer is recipe for major trouble if you don't know what you're doing. The functional requirement makes now a bit more sense. Your best bet is using IceFaces' push or poll component which in turn causes JavaScript in the client side to do a window.location on the desired URL.
I eventually fell back to my own way of doing it.
I'm putting the JSF bean into a session attribute with a portable renderer injected as a property. The session attribute is used since Spring cannot get the "View" scope. If there is a way for Spring to do so, that saves a lot of potential pitfalls, but alas I do not know how.
Once the page loads, a jquery AJAX call is made to a Spring Controller, which gets the JSF bean out of the session, removing it in the process, and proceeds to "validate it". As it proceeds, it sticks the current completion status into a session attribute and calls the bean function that invokes the portable renderer, which in turn updates the progress meter.
Also part of the page load function, is a separate function that calls another Spring Controller, which returns the completed status object, which may/may not have error messages.
I plan to remove the second controller by just checking values already on the page that get rendered by the portable renderer and publishing all those errors into the bean, which can then be rendered easily and dependably.
This way, as BalusC said, removes the creation of threads not directly spawned by the container and allows me to redirect automatically via window.location on successful completion.
If there is a better way to do this, which I imagine there is, please do add an answer. My knowledge with Icefaces and JSF is severely lacking currently and I'd thank anyone with the best way to do this.