Posted by nedjo on June 25, 2006 at 8:38pm
We've talked about future CCK tie-ins to the form builder, and are keeping this in mind as a future add-on.
What about Views?
Views module provides a code-accessible representation of tables, fields, etc. Presumably, on this basis we could pre-populate a draft form array, or provide a data reference for the form builder (default values for fields, etc.).
Comments
say it again
Hi Nedjo,
it must be late at night but your thought went right over my head. Could you feed it to me in bite-sized chunks? =)
-R
I guess I was more jotting down a thought than explaining it ;)
So here goes.
I think we (I, at least) have had a mental image of form building as something we'll do from scratch. Start with a blank slate, build form elements one by one. Or else start with a form similar to what we need, and modify it. This is basically automating what we currently do for modules--either we start writing code or we take a similar form and change it to our needs.
But, in many cases, by the time we are building a form we in fact have a lot more we could potentially work with. For example, we might already have designed some database tables. These tables hold information that, if we could access them, will provide some important clues as to what we want for form elements. What fields are there? Where do these fields relate to other tables (foreign keys)?
And that's part of what Views does--expose tables and their fields and attributes. Of course, it does so selectively and for its own distinct purposes.
Nonetheless, a possible workflow for building a new module might be:
(a) Code analyzes views data and builds skeletal form with referenced fields, which is then passed to the formbuilder; or
(b) View data are passed directly to formbuilder, and used in the interface. E.g., added to list of available fields for creation.
Import / export API
Views would certainly be a good place to start with this, but ultimately, the Import / Export API that I'm working on would be a more suitable candidate for this. The API performs a similar function to Views, in that it allows database structures to be defined as structured arrays through hooks. However, unlike views, its definition is not node-centric (it is, shall we say, 'entity-agnostic'), and it is trying to diverge from the 'selectively useful' aspect of the Views definition system. In fact, my aim is to even make the API 'data-source agnostic', so that it is even able to allow for the definition of data entities that aren't defined in the database, e.g. config files, uploaded files.
Adrian (one of my mentors for this project) would actually like to see this definition system become the foundation for FAPI 2.0. It could even become the foundation for Views itself - who knows? But this is still work in progress, and since it has the same timeframe and deadlines as the AJAX form builder, it's not a practical option for other SoC projects to make use of it (not this year, anyway).
I'd say that the AJAX form builder will probably have to make do with what's available in Drupal core at the moment, and rely on defining form snippets, and such things, from scratch within its own code.
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
That makes a lot of sense
Thanks Jeremy, that indeed sounds like the way to go. I'll look forward to seeing the data array structure as it develops. Likely we can come back to this as you suggest post-SoC. That said, I suppose it wouldn't be a bad idea for Avi to be in the loop as you define your data structure. That way he can keep it in mind. And, I suppose, possibly that part of your project - the array format - would be stable/mature early enough for him to look at using if he wishes.
sure!
Yeah... We can certainly do things the way it makes any future development in this direction easier.