General discussion on custom controls

I was testing recently some of the controls that should map the standard html/form 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:
obj.getContent('box/text').setAttribute('name', 'one_line');
obj.getContent('box/text').setAttribute('readonly', 'readonly');
obj.getContent('box/text').setAttribute('disabled', 'true');

But it seems that after they are written you cannot use this method
I've used ...
var tmp = document.forms[0].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 ??

Best Regards
Bogdan

I've also noticed that 2.0 controls aren't connected to their HTML peers at run-time. That is if you call setAttribute() or some data model methods, the changes aren't been propogated to the peer unless refresh() is then called. Unfortunately, calling refresh() can cause problems with focus and selection, especially if it's called on a component currently owning the focus.

I'm sorry, no solution here, just comments...

Interesting...

Actually never before I thought about using AW common controls as replacement for standard HTML elements, i.e. something that one would place inside the FORM with standard submit -> roundtrip to the server -> rewrite page. I always imagined some sort of 'single page' application where you keep the application state on the client, produce the complete UI dynamically from javascript and communicate with the server through HTTPRequest object without leaving the current page.

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?

Alex, in my case, I have a mixture of dynamic and conventional HTML components. That is I have a form that's structured like this:

[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

I use javascript to dynamically generate the form and submit it.

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 also had to choose between one context / page on the client with underlying http request using javascript and the context on the server and I chose the server side to leverage from portal and workflow integration. On the serverside you can also leverage from many proven features (caching, paging, etc...) that makes it simpler, less risky than to implement the same on the client.

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.

my little mockup above looks pretty bad, so here's the actual layout mockup: som-dev.ucsd.edu/sit_sr/addaccount.html

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.

My reason for posting such a general issue is that using a single GUI for the entire application makes easier to implement and lets you focus on the actual goals.
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...

To alex :

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!!!