Is edit-in-place the best solution?

Most AW developers, I presume, are designing web based business applications or something similar - not brochure-ware web sites. Most of us are dealing with large volumes of data and this is why the ActiveWidgets Grid is so attractive – it provides a way to display large volumes of data in a professional and intuitive way – far better than an HTML table, anyway. Many of our users that are migrating from legacy Desktop applications will find it familiar and therefore easy to use.

The missing piece, however, seems to be the editing of the data. Ideally, it should be done in a similar way, i.e. something that compliments the AW Grid and gives the user a “rich internet experience”.

Although Alex has developed a whole bunch of dialog objects in Ver 2, it seems as if he is attempting to solve the data editing issue by providing an edit-in-place solution. While I am sure some people will make use of it, in practice, I am not sure that edit-in-place is the ideal way to capture data - especially if you have more than 6 or 7 columns per record. A much better way, I believe, would be the more traditional Browse/Form paradigm one finds in Desktop applications. Not only is it more intuitive to the user, but it also solves the problem of capturing lengthy records (which require the layout and useability of a regular form).

The problem with this, of course, is the loading and reloading of pages and the loss of 'state' - and this is why edit-in-place solutions are often the de facto solution.

I feel, however, that a browse/form solution could be achieved using a combination of the AW Grid, the AW dialog controls and a bit of fancy Javascript. In fact, I have come very close to achieving this but have become frustrated because I cannot call some basic methods in the AW2 beta (such as refresh and setCurrentId) and because of a number of bugs in AW2 which remain unresolved. The lack of documentation hasn't helped either!

It seems as if Alex is struggling to get the edit-in-place to work across all browsers and is pouring all his resources into this functionality when, I believe, he should rather be concentrating on a browse/form paradigm. This would make it a far better product than some of the current competitors (such as EBA DataGrid and Rico LiveGrid).

I have created an example of a Browse/Form application using the AW Grid and AW Dialog objects which you can view at

http://www.legalsuite.co.za/aw/formtest.php

As you can see, it has a lot of potential, but the code is very messy and it needs a lot more functionality. Basically, Alex needs to decide where to concentrate his limited resources and assist with some of the finer details and also fix a number of bugs to make the Browse/Form paradigm a viable alternative.

Hopefully other developers feel the same and we can jointly persuade Alex to provide us with the tools we need and which will be far better suited to the task at hand.

Basically, I believe Alex should put the edit-in-place solution on the back burner for now and rather concentrate on developing a fantastic dialog box solution which is tightly integrated with the AW Grid that will provide a data entry solution which will knock the socks off the competition.

What do you think? Your comments would be appreciated.

Rick, I agree with you. The application I'm working uses form based editing - in my case user doubleclicks record in the grid and this gets copied into a form in lower half of page for editing. You could say that having edit-in-place is fewer steps for the user to go thru, but I think the extraction into a form gives editing a more deliberate and familiar feel. Also I'm sure that it depends on the app - I can imagine that in financial apps i.e. stock prices etc.. it may be desirable to have edit-in-place (although my app is not a financial one).

Alex did open this discussion a while back at end of Nov (http://www.activewidgets.com/javascript.forum.9201.20/please-comment-cell-editing-changing.html), so it may be late to change strategic direction..?

...sorry, I also meant to congratulate you on sharing a great looking example...

Rick & Will, totally agree.
The master-part of an APP should use forms to edit/validate data.
But I don't think that Alex should restrict a specific use of browse/form.(other than provide neccessary events/properties to do almost everything).Althought I know that the hardest part of creating forms is establish the environment (not only data, but container,interaction,inputs....)

IMHO (as I understand from your words) The question would be:
Is it possible to integrate a form-environment standarization?
(difficult to answer as it is up to each developer how standats helps or not)

On the other hand there are a lot of situations where an cell-edition is a very useful (and easy) way to manage accessory-data/customization/etc.. .
Therefor both are needed to create a versatile and powerful UI.

P.D. Fantastic sample Rick,
Thanks

It's all what the specs of the project call for. I am replacing a Windows application that has a data grid with in-place editing and that is what I need to provide. We are actually holding up release until the in-place editing is there and solid. We never edit more then a handfull of rows because the developers of the Windows app knew that would be cumberson for the user so they just don't allow it. As for editing in a typical form style, tou can do that right now, today, with no other things needing finsihed by Alex. You just have to be a little creative. I have written a set of popup dialogs that can easily be 'stuffed' with controls to edit the data. Then when they press some "Update" button, the values could be gathered and replaced in the original grid. That can be done today. I'm sorry, but I can't share the popup dialog windows with the group at this time due to some restrictions by my employer. But I will provide some information on it at a later time once our product is released. My dialogs are moveable, you can have more then one on a page, move to front when clicked and can be hidden to be used again without having to re-create them. It took less then a day to create them in 2.0, it just takes some imagination and good planning.

So my vote would be to see Alex get the current bug resolved on IE, then on the rest of the browsers. But in my opinion, in-place-editing is an absolute must have.

Jim

It's a pity you can't share your ideas and code with the rest of the AW community. I understand you are bound to the wishes of your employer but maybe if you offered some of your code as "open source" and allowed the community (and Alex) to assist you in developing what you have so far, it will be beneficial to you (and your employer) in the long run.

I am sure I could help and I have noticed there are some excellent other developers who contribute to this forum. Together we could give you ideas and maybe even improve your code here and there. This is the spirit and advantages of open source development.

Maybe we need to create a basic standard or template framework made up of JS or PHP classes which are wrappers for the AW methods which we all use and contribute towards. I can develop a searching class, i.e. how to search the grid and filter it via AJAX. You could share your fancy forms. Rick Villela and Carlos and Will etc. could all contribute something I am sure.

If Alex saw which way the AW community he would also chip in and make mods which we need. Together we would achieve a lot more than hanging on to our own source code.

I have given two code examples (AJAX filtering and this one) which have been warmly received by other developers. But I am relatively new to AW and without documentation, I feel like a blind man leading other blind people. It seems you have one eye open and, as they say, in the land of the blind, the man with one eye is king! Speak to your employer and see what he says. We need you to share your knowledge and maybe even write a few white papers or develop a few classes for the rest of the community. I am willing to assist wherever I can.

A basic AW framework would allow many other users to get started a lot quicker with AW and it would build up a bigger and better community to the mutual benefit of us all. At the moment I feel it is stagnating and I am getting a bit frustrated. We have development time frames and they are not infinite. I need to see this product going in the right direction otherwise I may have to look elsewhere for a temporary solution and then re-look at it in 6 months time.

I agree with you whole heartedly. But I write software for the government and military use. They will not allow me to publish anything that is being used in their programs. I try to contribute what I can to help people out.

I am thinking of starting a website of ActiveWidget lovers where we can create a set of base classes for all to share. On that site I think I can create classes that are usefull to all but not expose what I am doing at work. Just to let you know what we are doing with AW, our application will have no HTML once we release our 2.0 version! Everything in the application is rendered with AW (oops, except a calendar control that I might create in AW after the dust settles with 2.0).

As you might have already seen, I did post a message that was a basic tutorial on how to create your own controls including custom functions. I want everyone to see the power of the framework and not just the grid. Up until a little bit ago, I think I was the only one creating controls. I asked questions on the forum about composit controls and got no responses at all. Now I can see that there are more and more people that are interested in writing their own controls and I love it.

This community is going to grow quickly once 2.0 goes final. I can't wait!

Jim

Sounds great - I would be happy to assist with such a web site.

BTW - what server side language do you use? I use PHP.

I am a huge PHP fan. All of the sites that I run use it.

Thanks for the offer.

grow cube ver 2 solution