Does ColdBox have any tools to quickly build out basic list/edit/save
areas for admin of supporting data tables, basic CRUD stuff? Or do you
all just built these things by hand each time? (Not that ColdBox
doesn't let you do that with a minimum of fuss, just wondering if
there are generic shortcuts people use.)
Thanks,
Dave
Is there a good scaffolding plugin for ColdBox? I know that ORM helps you get the backend for that in place quickly, but writing all of the forms takes a while still…
Never used it. But maybe this can help.
http://wiki.coldbox.org/wiki/Projects:LookupManager.cfm
- Gabriel
Maybe its time somebody built one? (except me of course 
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Scaffolding is not supported directly.
But there is
http://www.coldbox.org/forgebox/view/Illudium-Scaffolding-Templates
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of enigment
Sent: Saturday, 16 October 2010 7:08 AM
To: coldbox@googlegroups.com
Subject: [coldbox:6272] Generic admin/CRUD toolsDoes ColdBox have any tools to quickly build out basic list/edit/save
areas for
admin of supporting data tables, basic CRUD stuff? Or do you all just
built
these things by hand each time? (Not that ColdBox doesn't let you do that
with a minimum of fuss, just wondering if there are generic shortcuts
people
Louis, it looks like maybe you started with cbox-form-daddy, but
unless I'm missing something, currently it's just a default ColdBox
app. Am I confused? I was just browsing the files, trying to
understand exactly what it was, so maybe I missed some key bits.
Dave
It's all in the plugins directory, but to second your request I'd like
to hear what the project does or even better see an example. This is
very relevant to what I am working on.
.brett
Form Daddy was the brain child of Henrik Joreteg and Myself. We started it about a year ago and were successfull with the alpha that’s only.
Basically, it is a way to describe forms via json or implicit structure/array notation. We created the Validator plugin because of it so we could do all kinds of validations. The idea is you describe forms in the configuration, then you ask form daddy for a form, it gives you a Form object that you can use to render out the form in its standard styles. Or you can ask the Form object to give you a collection of fields and then you iterate and display as you see fit.
It also had the ability to bind the form to the request context ffor validation purposes. So on a form submit you could do this
myform = FormDaddy.giveMe(“formID”).bind(event)
Then it will bind and validate all the incoming form elements to that specific form. Then you can ask the form for validation: myform.validate(), myform.getErrors(), etc.
Basically server side validation. The next step was to add UI validation via the renderig of the form and have it in a javascript interface so it could be added in ANY validation system.
Anyways, if someone would like to pick it up I would appreciate it, I can’t until 3.0 is out.
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Very cool Louis and Henrik, good stuff. I have some questions and some ideas. I
know you're concentrating on 3.0 now, don't want to monopolize your time, but
this relates very much to some things I've been thinking about, and I wanted to
touch base before possibly getting involved. Nothing here should be taken as
criticism of FormDaddy, quite the contrary, I very much like where it's going,
and it inspired me to put down some of my ideas.
I'm also very much not talking only to Louis, though I'd love to hear his
thinking on it, but also to anyone else who's interested. This is a long post,
apologies in advance.
Re FormDaddy specifically:
- I'd expect all values to be HTMLEditFormat encoded. Is there a philosophical
reason why that wasn't done, or is this just an early version?
- Either I don't understand something, or the radio widget is unfinished. First,
the renderer doesn't have logic to check itself or not, or a variable for the
active value, as opposed to the value for this individual radio button.
Second, radios are really only useful as a set, and I don't see a convention
or other way to provide a collection of values and display values.
Did you have a design somewhere (in your heads maybe?) that addresses these
issues?
A simple convention that looks for an array of value=displayValue strings in
rc.<fieldname>_options might be fine.
- Related, widgets to render HTML selects and multiple checkboxes would be
useful too. They'd need similar infrastructure to provide a collection of
available options. I'd suggest that both checkboxes and radios assume that they
are or may be multiple, rather than having separate multi-checkbox and
multi-radio types.
- The ability to pass in an errors collection would be very useful, to redisplay
a form with error messages displayed and invalid fields highlighted. An array of
errors in {highlightID: message} format might make sense.
Thinking about the big picture of a full generic CRUD tool, I'm thinking about
handler code something like this, assuming the various 'Daddy' plugins are DI'd
in:
// UserRole.list:
ListDaddy.list('UserRole');
// UserRole.edit:
FormDaddy.edit('UserRole', rc.UserRoleID);
// UserRole.save
errors = ServiceDaddy.save('UserRole', rc);
if(ArrayLen(errors))
FormDaddy.edit('UserRole', rc.UserRoleID, errors);
else
setNextEvent('UserRole.list');
// UserRole.delete
errors = ServiceDaddy.delete('UserRole', rc.UserRoleID);
if(ArrayLen(errors))
// tell user and display something
else
setNextEvent('UserRole.list');
The idea is to provide a high level of syntactic sugar for building CRUD areas
with minimal code, while maintaining healthy MVC separation, and allowing enough
control that the tools could be used in not-completely-standard situations.
In that light, there are some other components that would be good to have I
think:
- A generic list rendering tool analguous to FormDaddy
Many of the overall and field/column configuration options would be the same,
some not. For instance, list columns don't need validation, but do need
alignment.
It should be possible for a custom column rendering UDF to access the values
from multiple fields, and I'm not sure how to arrange that.
Another helpful config would be a headerUDF, which could be used to render a
search form or other custom HTML above the list. Possibly a footerUDF would be
useful too.
- A generic service to manage the actual save and delete operations
The save tool should validate first, and return an array or errors if invalid
fields are found. Personally, I don't think validation belongs at the view
layer; it's a model function, especially important if you expose an abstract API
that may be accessed without involving your app's forms at all.
There are of course pluses to client-side validation, and I don't want to
start a big discussion here about the pros and cons of ajax submits and other
alternative strategies. The big thing here I think is that validation specs
shouldn't be localized to the form definition; see next point.
- A metadata service used by the above components for configuration and defaults
All these operations need much of the same metadata -- table and column/field
names and user-friendly labels, PK column name, FK column names and related
tables and PK columns, etc.. Assuming we can't just abstract all this away with
CF9 ORM, which is currently the case for folks using Railo (including me for
some projects), it would be great to provide a central metadata service that
these other plugins, and possibly others in the future, could access.
Ideally the underlying data it works from could be initialized from existing
beans and/or a datasource, then customized from there. In simple cases, the
defaults would be fine.
This sounds very related to Transfer, if I'm not mistaken (which I easily
could be since I've only just started looking at it and have never used it).
However, though Transfer uses this sort of metadata internally, and ColdBox has
tools to build default configs, I didn't see how to ask Transfer for that info,
and these services would need additional info.
Are there other projects that would be better suited to this? I'm also not
sure how to both leverage existing technologies and extend them for this
purpose. Any thoughts?
I know that's an ambitious collection of ideas. What do folks think about all
this?
I'm very willing to get involved here myself, but as I said, I wanted to see
what others have to say, esp FormDaddy's daddies.
Dave