Hello,
I'm Jeff Balogh, and I'd like to get an SoC spot with Dojo this summer. I think
it would be fun to build a drag & drop form editor for Dojo/Dijit. I'm
interested in doing this because the the other project I work on, DrProject is trying to move to
user-configurable dynamic forms, and a form editor would help us out a lot. I
think other people could benefit from this as a part of Dijit, and I could
benefit from a Dojo mentor.
I've been doing open source since SoC 2007, when I started work on DrProject (a
fork of Trac that supports multiple projects and tries to be simpler than Trac.)
It's written in Python, which is my strongest language. Right now I'm at the
PyCon sprints, working on core Python.
I got started with Dojo in January, when I added some Dojo/Dijit niceness to
DrP. I've hacked up some of the Dijit code to make links work in Dijit menus,
but it's nothing I would show off.
The design of the editor is still swirling around in my head, but I'd like to
write about my ideas so I can get some feedback.
The interface would normally start with a blank box, the canvas for the future
form. On one side, I'd have the possible field types, from dijit.form. A user
would drag one of these into the form and a new dijit would be created inside
the form. On the other side would be a configuration box. When a field is
selected, the user would be able to configure the title, default value,
constraints supported by the dijit, etc.
I think it would be helpful to have multiple backends, but I'd start with a
simple JSON backend. When the user wants to save a form configuration, a json
representation of the form state would be sent to the server. The server can
then do what it wants with the json, translating it to some other form or
storing the json directly.
Any given configuration won't require every dijit, so we could send the minimum
build profile to create an optimized build.
Once I get some feedback on this, I'll come up with some progress milestones for
the summer.
Thanks.
Bunkai and Wavemaker
Hi Jeff,
Sounds pretty good!
I don't fully get your use case though - the dynamic fields the user creates are stored in separate DB fields? Or serialized into a single json/pickle field or some multi-table-meta-field structure? If its the former, then there is a constrained list of fields and its just re-arranging them in a box?
Server-side there's going to need to be some logic to turn your JSON back into markup for the form right? Is there any reason we couldn't serialize it to dojo markup first? Since that way there's no need for code to "turn it back" into markup.
How are you planning on figuring out the appropriate/available properties and their values for the different widgets?
Other stuff to look at:
One of our SoC mentors (Peter Svennson) built Bunkai, which might give you some inspiration. There's also WaveMaker which is worth a look.
SMD
it might also be worth thinking about SMD, there's an article on SitePen about it today - http://www.sitepen.com/blog/2008/03/19/pluggable-web-services-with-smd/
Re: Questions
Hey Rob,
> I don't fully get your use case though - the dynamic fields the user creates are
> stored in separate DB fields? Or serialized into a single json/pickle field or
> some multi-table-meta-field structure?
I think this decision would be best left to the people who use the editor; we'd
provide a flexible output format, so they could store a pickled blob, or come up
with a more elaborate db schema. Since json is pretty easy to work with, I
thought that would be a good start for the backend storage.
> If its the former, then there is a constrained list of fields and its just
> re-arranging them in a box?
This is true; providing the full set of fields may not always be possible (or
desirable), so it would need to handle whitelisting or blacklisting of
possibilities.
> Server-side there's going to need to be some logic to turn your JSON back into
> markup for the form right? Is there any reason we couldn't serialize it to dojo
> markup first? Since that way there's no need for code to "turn it back" into
> markup.
By dojo markup, do you mean dojofied html or something like dojox dtl? These
could also work, but may not be as easy to manipulate if people want to use some
other form of markup.
> How are you planning on figuring out the appropriate/available properties and
> their values for the different widgets?
This is one of the difficult parts. My initial thought is to use a small
wrapper around a widget providing the appropriate metadata, but that's not ideal
because the wrapper is then tied to the api of that widget. I suppose it
wouldn't be too bad, since dojo will probably be fairly stable now, but I'd be
happier if there wasn't a tight coupling.
It may not be possible to get useful metadata about a widget without coupling,
so that's a compromise we'll have to look into. Suggestions are certainly
welcome. :)
> Other stuff to look at: One of our SoC mentors (Peter Svennson) built Bunkai,
> which might give you some inspiration. There's also WaveMaker which is worth a
> look.
Interesting, thanks. Peter's editor is cool, and fairly close to what I have in
mind, although I'd like to make something more lightweight, if possible.
> it might also be worth thinking about SMD, there's an article on SitePen about it
> today - http://www.sitepen.com/blog/2008/03/19/pluggable-web-services-with-smd/
The json
schema proposal could be useful for specifying a mapping to a static db
schema. Thanks.
WaveMaker
It might be worth looking at WaveMaker and seeing if there's any work you can do with that. At the latest developer day they said they might be willing to open source the WYSIWYG part of it
Some thoughts on metadata
Hi All! Finally I realized that this thread is where everything is happening :)
I just want to give my thoughts on the metadata of the Widgets;
When I wrote the first version of Bunkai, I reused an available file that described the Dijits in the system and is used as part of the suite of form tests in the source tree. One idea would be to fiddle a bit with the build system to generate more beefy metadata files for all widgets (or all components, if needed) which could then be used by the editor and be completely separate (of course) from the Dijit's themselves.
I had some issues with the current file, since the file<->Dijit mapping is not complete, so some files in the source tree define more than one thing. And one of the things one such metadata fiddle with the build system could do is to map where each dijit actually reside, so that it becomes possible to load and manipulate them simpler, for an editor.
But then, as a beginning, maybe a combination of non-function property enumeration of a Dijit and a naming scheme could provide all necessary metadata?
I mean that if you just access the class object of the Dijit you have a lot of info for free, and if you assume that certain names, or parts of names of properties carry information, it might be enough.
WDYT?
Cheers,
PS
Re: Some thoughts on metadata
> But then, as a beginning, maybe a combination of non-function property
> enumeration of a Dijit and a naming scheme could provide all necessary
> metadata?
> I mean that if you just access the class object of the Dijit you have a lot of
> info for free, and if you assume that certain names, or parts of names of
> properties carry information, it might be enough.
I like this idea. It would be very nice to use a bit of introspection to find
the right properties for the object, rather than depending on an external file
(which won't necessarily be up to date).