General discussion on custom controls
It seems to me that at this moment the controls are not capable of replacing the standard controls.
I have found some ways to make the Input for instance to behave like a input type=text so far...
Before writing the doc you can use:
But it seems that after they are written you cannot use this method
I've used ...
var tmp = document.forms.elements['one_line'];
tmp.readOnly = false;
tmp.disabled = false;
So I have operated externally on the input field written by Ui.Input
Also I think that Buttons should also contain a hidden field in order to allow the button to appear as submitted.
The combobox does not have yet implemented value,
There is no implementation of textarea ?
Will those controls be corrected or implemented in order to allow the replacement of the standard ones ??
I'm sorry, no solution here, just comments...
In theory it would be possible to extend AW controls so that they work as FORM elements (adding INPUT type=hidden tag where necessary). But I am still undecided in this case where do you see the benefit of using AW controls over the standard HTML elements, if you still submit to the server and rewrite the page each time?
[start of form] [b]Employee Name[/b]: [input box] (AW component with suggest and autocomplete; DB driven) [b]ID[/b]: [read only] (regular HTML populated from result of search above) [b]Department[/b]: (regular HTML populated from result of search above) [b]Email[/b]: [input box] (regular HTML populated from result of search above) [b]phone ext[/b]: [input box] (regular HTML populated from result of search above) [b]Supervisor Name[/b]: [input box] (AW component with suggest and autocomplete; DB driven) [b]Email[/b]: [input box] (regular HTML populated from result of search above) [b]phone ext[/b]: [input box] (regular HTML populated from result of search above) [add account ] (regular HTML submit button) [end of form]
because of the layout requirements, I cannot move all of the active components outside of the form. So, I need to be able to intercept and cancel ENTER keys events inside the name search boxes
Alex 's comment is interesting, I was wandering why users keep asking for complicated features and actually was starting to worry about priorities in devlivering all these cases. Now I understand better, although still worrying if features will get prioritized adequately for my usage.
I choose AW because it really accelerates my development for the client part. I does and to me, I miss menus a lot more than pagination, supporting more than 55000 rows, etc... Again I can imagine my personal point of view is not shared by many.
also notie that the Index column contains input boxes that in the final implementation will become AW-enabled controls capable of validating account numbers in the background via a request to a web service.
Again, the final submission of the form is handled with a convential form POST, but data entry and validation leverages the Active Widgets framework.
You can post a form using the old fashioned way or using ajax capabilities. But if you can map the controls and get an independent UI it makes the difference.
And for the end-user manytimes the look is more important than the functionality... I think (I'm not sure) it's called Marketing :))
I'm just an engineer...
the benefit of using AW controls over the standard HTML elements :
So as to get the same UI for all controls on the page : an AW List or grid, with the same skin for the app...
Plus AW controls are much easier to use...
And we can create controls from existing controls...
So don't think to much about how we could use the controls, I personnally have infinite imagination for this!!!
This topic is archived.
Back to support forum
Version 2Looking for AW 2.6 ?
The old site is here.