add Validator to existing FormItem Validators in smartgwt - forms

in a smartgwt DynamicForm, how can I add a validator to an existing set of validators within a FormItem ?
The only method I found in the official api is "setValidator(Validator)", but this seems to overwrite all the existing ones.
I would prefer a java approach to this (i.e. using smartgwt api), but in the end, if no solutions are available, at least a "js" native method would do the job.
thanks

Most likely, you don't want to by trying to dynamically add a validator at all.
First, read the Data Binding section of the QuickStart Guide, which shows how you can add screen-specific validators to a form while still inheriting validators declared in the DataSource.
Second, if you're trying to dynamically change the list of validators because some data that validation depends on is changing, take a look at the CustomValidator instead.
If you have some reason to add a validator dynamically that isn't handled by these approaches, try explaining it in detail.
Finally, you can continue with your current approach (not recommended) if you just refactor such that you can provide all the appropriate validators to the FormItems in a single setValidators() call.

Related

Adding attributes to cq5 form using FormsHelper

I'm trying to add an attribute to the form tag of a cq5 form. I noticed that the output is generated using
FormsHelper.startForm(slingRequest, new JspSlingHttpServletResponseWrapper(pageContext));
I was curious how I can either:
alter the request so that the formHelper prints the form w/ the attributes I need
Hook into the actual print out to include the attributes I need.
Any help or direction would be good.
note:
I've already checkout out the javadoc for formshelper, done some searching via goolgle, and dev.day.com including the dev.day.com doc on developing forms.
thank you
API doesn't allow you to add any attributes to this tag. You can only specify desired CSS classes adding css property to the form component. Of course, you can also create component sling filter and response wrapper to rewrite created form, but it seems to be an overkill. I think better solution is using JS to add attributes client-side.

why use zend form decorators instead of individually rendering?

I am almost at the end of my rope trying to style my Zend form using decorators. Previously to avoid these issues I would create a form script extending zend_form, add whatever validators, labels, etc I needed then retrieved the element from my view script using $form->getElement('my_form_element');
that way I could wrap whatever css tags I wanted around the element. I thought I should learn how to use the built in decorators, but I'm starting to feel like it's a waste of my time. My old way seems easier, is there some reason I am not seeing that makes using custom decorators better?
In general decorators are used to dynamically add functionality without having to touch the code's core functionality and for a better re-usage of code. In Zend_Form however, I think that the decorator system (as well as Zend_Form in general) is unintuitive and heavily over-engineered and so it does exactly the opposite of what it should do: Help the developer to create better and more intuitive code faster.
In my opinion the usage of Zend_Form_Decorator makes only sense in the case where you have some extended logic that you plan to reuse throughout your project on multiple and different types of elements.
Let me give you two examples:
You want to add a tooltip icon next to an arbitrary form element with a nice icon and a fancy JavaScript hover box.
An element should be validated directly upon entering data by posting an AJAX request and adding either a green check mark on success or a red cross icon on failure next to the element.
With the decorator you can now separate the logic of the added functionality from that of the underlying element and so you can use the same code to add the tooltip and/or the live validation feature to a textbox element as well as any other element simply by adding all the decorators you want to the element.
There is also a great article from Matthew Weier O'Phinney, the lead developer of Zend Framwork, that gives some background insight on the motivations for using decorators along with a lot of examples: Decorators with Zend_Form
Decorators can come in handy if you have a specific repeatable markup for your forms, for example if you want to use Bootstrap. Other than that, especially if you have a good html/css person, I would avoid them.

Should I generate html form?

I'm building a php application that will have many modules/plugins. The issue is that creating smarty template for form's of each plugin and writing validation code for each looks redundant and at the same time using PHP to generate form will restrict the flexibility in controlling each form's layout structure the way I would have wanted.
Using PHP classes and inheritance you can write the validation and layout code once and overriding them whenever you need specific behaviour.

GWT 2.1 and the editor mechanism, how to?

I'm very confused about the new editor mecanism with GWT 2.1.
I can't understand how to provide errors with a simple TextBox.
For example I want a TextBox where text size is greater than 6 (for a password).
How can I simply provide a delegate to this textbox to handle this verification and use this textbox in the editor mecanism ?
Moreover, I don't understand differences between editor adapters and editor subtypes. How should I use these two features to create my own editor widget ?
official documentation is here:
http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideUiEditors.html
But it's not very clear.
There's a sample widget in DynaTableRf that implements a ZIP+4 input box as a subclass of ValueBox. A custom Parser is used to provide the input validation. The ValueBoxEditor adapter is used to transform the ValueBoxBase.getValueOrThrow() into an EditorError.
An "adapter" contains a reusable behavior that isn't tied to editing a specific kind of data. For example, the OptionalFieldEditor and the ListEditor don't really care about the T parameterization. An Editor subtype is primarily concerned with displaying an instance of the T type and may or may not embed a complex behavior.

How to extract labels from Symfony forms I18n Extract Task

I am quite aware that the extract task accepts application as a parameter, and thus one can't expect it too look into the forms folder.
However, I referred the link (below) and tried a couple of ways:
1. defining my proxy __() method
2. including the I18n helper in App Configuration
However, both aren't working.
Can anyone tell me how to extract these from the form classes?
Thanks
http://groups.google.com/group/symfony-devs/browse_thread/thread/1d034f5f7367fe0c
You need to use the i18n helper and add the translated strings manually to your XML/XLIFF files. The translations themselves work, it's just the i18n:extract task that doesn't look inside form classes so it has to be done manually. I hope they add this feature in Symfony 2.0.
See the first few paragraphs here: http://www.symfony-project.org/forms/1_4/en/08-Internationalisation-and-Localisation
There's a way to extract it altough it's not recommended by the developers:
In lib/i18n/extract/sfI18nApplicationExtract.class.php add:
$this->extractFromPhpFiles(sfConfig::get('sf_lib_dir').'/form');
to function extract()
In your form class's configure method add:
sfLoader::loadHelpers('I18N');
This way you can use the __() function in your form class.
I'm currently testing it. Will share my findings.