Page 2 of 2

Posted: Tue Oct 10, 2006 4:15 pm
by Christopher
The Ninja Space Goat wrote:A form controller would allow multi-page forms... (right arborint?)
That's actually an Application Controller. A Form Controller is just the three-state version of an Application Controller (initialize, submitted with errors, submitted accepted). The controller part accepts the HTTP request and sorts out what do display. The HTML could be generated, from templates, or a mix.

This sounds like this is an HTML generator.

Posted: Tue Oct 10, 2006 4:16 pm
by patrikG
For want of a better description here's CakePHP's wrote:Scaffolding is a way of getting the early parts of developing a web application started.
Early database schemas are volatile and subject to change, which is perfectly normal in
the early part of the design process. This has a downside: a web developer hates creating
forms that never will see real use. Scaffolding analyzes your database tables and creates standard
lists with add, delete and edit buttons, standard forms for editing and standard views for in-
specting a single item in the database.
aborint is right: don't worry about HTML, keep the classes simple. Forms can be complex enough as they are. Their purpose is to handle data, not how to prettify it.

Posted: Tue Oct 10, 2006 4:20 pm
by Christopher
The only HTML elements I generate are select, radio and checkbox because the have to be set to selected/checked.

Posted: Tue Oct 10, 2006 4:25 pm
by Ollie Saunders
So saffolding is creating simple forms from database tables? I never knew there was a name for that. But I am aware of the desire to do such a thing. It won't be in version 1 but it definately something I'm going to consider.
A Form Controller is just the three-state version of an Application Controller (initialize, submitted with errors, submitted accepted). The controller part accepts the HTTP request and sorts out what to display.
Then yes this is a form controller as well.

Posted: Tue Oct 10, 2006 4:27 pm
by patrikG
Scaffoling as concept was, AFAIK, introduced by Ruby on Rails (see: http://wiki.rubyonrails.org/rails/pages ... caffolding)

Posted: Tue Oct 10, 2006 7:16 pm
by Christopher
ole wrote:Then yes this is a form controller as well.
What would be cool to build is an Application Contoller that did both the PHP and Javascript sides ... maybe even some Ajax stuff. But that allowed flexiblity over the source of the HTML.

Posted: Wed Oct 11, 2006 12:29 am
by jmut
a bit off-topic but in the context:
Regarding the "scaffolding" term.

Quote from Code Complete, Second Edition by Steve McConnell. This term might come in various flavours of meaning but I am more likely to believe this one.
*Building Scaffolding to Test Individual Classes*
The term "scaffolding" comes from building construction. Scaffolding is built so that workers can reach parts of a building they couldn't reach otherwise. Software scaffolding is built for the sole purpose of making it easy to exercise code.
Further Reading
For several good examples of scaffolding, see Jon Bentley's essay "A Small Matter of Programming" in Programming Pearls, 2d ed. (2000).


One kind of scaffolding is a class that's dummied up so that it can be used by another class that's being tested. Such a class is called a "mock object" or "stub object" (Mackinnon, Freemand, and Craig 2000; Thomas and Hunt 2002). A similar approach can be used with low-level routines, which are called "stub routines." You can make a mock object or stub routines more or less realistic, depending on how much veracity you need.

Posted: Wed Oct 11, 2006 9:40 am
by patrikG
arborint wrote:
ole wrote:Then yes this is a form controller as well.
What would be cool to build is an Application Contoller that did both the PHP and Javascript sides ... maybe even some Ajax stuff. But that allowed flexiblity over the source of the HTML.
That would be cool indeed, but only with really, really, really careful planning - the pitfalls are immense.
For pure Javascript that would not be too complex - pre-scripted and ready on-load. But then, I don't think Javascript in forms is really beneficial.

AJAX is really another kettle of fish. Depending on how orthodox one is with regards to MVC it creates a nice little subversive sub-MVC within an application with the potential to mess things up. Or, if carefully applied, it takes it to another level. But planning that would be a wee bit of a headache.

If you have form-validation with AJAX in mind, on-change triggered combo-boxes and transforming elements, sure.
But again, it's very easy to create an "egg-laying wool-milk-sow", i.e. something that tries to be everything, yet is somewhat of a monster. Rather have a solid, pluggable form-controller first, then add AJAX & stuff as a plug-in. That way you have a clean architecture which AJAX doesn't break, but fits into.

Posted: Wed Oct 11, 2006 3:29 pm
by Ollie Saunders
patrikG wrote:
arborint wrote:
ole wrote:Then yes this is a form controller as well.
What would be cool to build is an Application Contoller that did both the PHP and Javascript sides ... maybe even some Ajax stuff. But that allowed flexiblity over the source of the HTML.
That would be cool indeed, but only with really, really, really careful planning - the pitfalls are immense.
I'm quite sure this has already been done by several people. Backbase seems really amazing but its very expensive.
AJAX is really another kettle of fish. Depending on how orthodox one is with regards to MVC it creates a nice little subversive sub-MVC within an application with the potential to mess things up. Or, if carefully applied, it takes it to another level. But planning that would be a wee bit of a headache.
Not really sure what you are saying here. The view part of MVC doesn't exist in the server side code of AJAX as the JS does all that.
If you have form-validation with AJAX in mind, on-change triggered combo-boxes and transforming elements, sure.
But again, it's very easy to create an "egg-laying wool-milk-sow", i.e. something that tries to be everything, yet is somewhat of a monster. Rather have a solid, pluggable form-controller first, then add AJAX & stuff as a plug-in. That way you have a clean architecture which AJAX doesn't break, but fits into.
Considering that the major AJAX libraries have already been written that kind of simple plug-in AJAX is probably what interests me more than anything else. I've already designed it so that there are separate packages for handling I/O so AJAX receievers and renders wouldn't be too hard. Although I need to brush up on JS and properly study XML, SOAP and the god know how many thousands of XML other based technologies before I attempt such a thing. XML, SOAP, WSDL, Schema, XSLT, XHTML, XForms, XPath, XSmurfingHellHowAmISupposedToLearnAllThis.

Posted: Fri Oct 13, 2006 4:51 am
by patrikG
ole wrote:
AJAX is really another kettle of fish. Depending on how orthodox one is with regards to MVC it creates a nice little subversive sub-MVC within an application with the potential to mess things up. Or, if carefully applied, it takes it to another level. But planning that would be a wee bit of a headache.
Not really sure what you are saying here. The view part of MVC doesn't exist in the server side code of AJAX as the JS does all that.
Yup, you're right. My silliness.