Usabilitiy Improvements

I'd like to include as standard in the admin and available in the API as many usability tweaks as possible, mostly little javascript calls, including:

Button disabling on submit: simple little javascript to prevent folks from double-submissions

Easy ability to swap the visibility of layers: tremendously helpful for focusing the user's attention on what's important... click the WIP "Forgot password?" row-link at http://traveleroverseas.com/login for an example.

And many more I'll think of in the next few hours and days.

Sounds like we need a standard form API.

Then these usability tweaks would be easy to do-- the submit button, for instance, would always disable itself automatically when clicked.

I have some experience in form APIs so don't mind working it up as part of my other changes, but if someone else wants to volunteer, jump on in.

Probably need to do the form API before I start looking at the Manager Config API so it can use it.

Sounds like we need a standard form API.

Then these usability tweaks would be easy to do-- the submit button, for instance, would always disable itself automatically when clicked.

I have some experience in form APIs so don't mind working it up as part of my other changes, but if someone else wants to volunteer, jump on in.

Probably need to do the form API before I start looking at the Manager Config API so it can use it.

I don't agree with this plan. Once again, I think we need to isolate the core features from UI options. A standard form API is not necessary, and would simply introduce additional user training issues and core bloat. I believe the only thing we need here are snippets/modules/plug-ins (we really need to discuss this too, so many different types of code objects, what's the real difference?) that allow generation of forms, processing of forms, etc. without limiting the ability of custom forms/form processing. I have a MailForm snippet that builds custom contact forms by providing default, and per-alias customization of every aspect of the form, including form headers, the form itself, form footers, form validation, form processing (e.g. send email, commit data, etc.), as well as failed and successful submission messages. With some refactoring and work on object abstraction in the core, we can find a way to manage these pieces as related entities via a wizard in the manager. In the meantime, I can add a few tweaks to the existing MailForm snippet to make it less email specific, and you can author a form in a matter of minutes by simply defining a few chunks and snippets as appropriate.

Just my vision of forms processing...

I don't agree with this plan. Once again, I think we need to isolate the core features from UI options. A standard form API is not necessary, and would simply introduce additional user training issues and core bloat.

It seems we are often at odds, Jason.

I fail to see how having a consistent way to produce forms in the system introduces bloat OR user training issues-- especially since the users would never see it.

At the moment there is no consistency in input. The forms on one page may not work like any other form, especially once snippets/modules/whatever can accept input in the backend (like they can already do).

There is an enormous difference between an enduser API and an internal API that the program uses to cut down on code redudancy and ensure consistency. The ONLY thing that I'm interested in is the core API used internally.

As such, I fail to see why having a consistent means for programmers to build the forms is bad. Can you imagine if the operating systems didn't have a standard API for building widgets and elements and just let developers do whatever? I, for one, wouldn't even bother turning a computer on. There has to be some standards and consistency somewhere.

Anyway, please explain what I'm failing to see here. Please?

I don't agree with this plan. Once again, I think we need to isolate the core features from UI options. A standard form API is not necessary, and would simply introduce additional user training issues and core bloat.

It seems we are often at odds, Jason.

I fail to see how having a consistent way to produce forms in the system introduces bloat OR user training issues-- especially since the users would never see it.

At the moment there is no consistency in input. The forms on one page may not work like any other form, especially once snippets/modules/whatever can accept input in the backend (like they can already do).

There is an enormous difference between an enduser API and an internal API that the program uses to cut down on code redudancy and ensure consistency. The ONLY thing that I'm interested in is the core API used internally.

As such, I fail to see why having a consistent means for programmers to build the forms is bad. Can you imagine if the operating systems didn't have a standard API for building widgets and elements and just let developers do whatever? I, for one, wouldn't even bother turning a computer on. There has to be some standards and consistency somewhere.

Anyway, please explain what I'm failing to see here. Please?

I'm trying to get to the same end result you are, but instead of isolating developer and end-user API's, I'm attempting to abstract them down to a resuable state. In other words, whatever API's the core has available should be inclusive of all types of object management, including getting/setting properties, executing class functions on the instances, even evaluating events/rules, display formatters, or defining relationships. In this way, your form API becomes just another set of class variables, and functions, extended from the core which define the extended capabilities I'm talking about. Instead of a dedicated API function, you use a core API to get/set/execute/evaluate expressions/etc., in a standard, user-friendly way, on the various object definitions.

So, instead if something like this...

$modx->buildForm(param1, param2, etc.)

you might use something like this...

$modx->set(subject, predicate)
OR
$modx->set($form->action, $controller->getRequestParam('action'))

where subject is the target object attribute to set a value for, and predicate is the expression to evaluate. This is a bad example and perhaps we could work together to see how this can be used to build just about any kind of web application you can imagine; I just hope I'm able to illustrate what I'm trying to talk about in such abstract terms.

I really not pulling this out of my a$%; I've worked with a J2EE framework based on similar concepts, where we used this type of code to build custom JSP tag libraries for the designers -- in our case, we'd just need to work out very simple syntax for representing the objects/expressions site designers/admins would often be using directly in the templates, or defining on a wizard/form in the manager.

Well, my personal thought on this is that Etomite owes its success thus far by walking a fine line between power and simplicity.

To me, a syntax that looks like:

$modx->set($form->action, $controller->getRequestParam('action'))

is going far, far away from the "simplicity".

At the moment one of the cool things about Etomite is that even entry level programmers can (and do) contribute code. I have a sneaky feeling that once you have $class_a->method($class_b->method2(), $class_c->method3()) syntaxes, you'll be losing a large number of people.

Knowing how many times I have seen "I am not a programmer" in the Etomite forums (and even these boards here), a syntax like you have above worries me a good deal. Everything in the current codebase is named in such a way that it makes logical sense and is easy to just pick up and go with, yet still has enough power that even someone with as many years of programming as I have still can be excited about it.

While undeniably powerful, when thinking about the roots of Etomite/modX and how many times we've been asked to keep things simple, the syntax above makes me cringe. You have three different objects there, with two being passed as arguments. Once we go down this road, I can see this getting even more complicated.

Which isn't to say that your way is bad or that I don't appreciate it, the opposite is actually the case. I'm just very afraid that we will quickly depart from anything resembling the plain logic and readability that the code currently can claim and so before we do that, I'd venture to say that we'd need to make sure that everyone -- especially Ryan and Raymond -- are on board.

Because, in my opinion, if we fully embrace your way, we are talking about a whole other project.

I've consider this as a separate object framework for PHP, because I've found nothing comparable without requiring PHP 5, and even then you have to use specially made builders and such to make it happen. The thing is, even if we implement this in the core, you can build whatever super-simple API you want on top of it, including custom API extensions to core objects and user-defined objects as well.

I see your points about typical PHP programmers and complication, but I can't help but see this as simpler; I've had about 8 years of object-oriented programming experience, and I think in objects all the time (even when not programming).

I have another thread with more information on this that I'd like feedback on from Raymond, et al.; I'm certainly not forcing this on the project; just offering my vision to the project if it's interested.

Wow... I'm leaning more towards simplicity. I for one would struggle with nested function/class/object/whatever calls. The relative simplicity of Etomite and it's subtle power is what drew me to it in the first place.

Simultaneous submits... heh

I really like the thought of a super-charged underpinnings with a wizardlike interface on top for folks like me. Two birds, one stone, death everywhere.

I've had about 8 years of object-oriented programming experience, and I think in objects all the time (even when not programming).

Of course, coming from a fairly extensive OO background myself, something I am sure you realize is that even in version 5, OO in PHP remains little more than a kludge.

In addition, because so many people still are on 4, whatever we do with OO must also work in that version, where OO is nothing more than fancy arrays.

So far everytime I've gotten very far into real OO work with PHP I've ended up struggling more in getting PHP to do what it should than I have writing the application itself.

Just something to keep in mind...