[jifty-devel] Ideas for Jifty plugins

Jesse Vincent jesse at bestpractical.com
Sat Jan 27 00:37:43 EST 2007

On Fri, Jan 26, 2007 at 04:48:02PM -0600, Andrew Sterling Hanenkamp wrote:
> I had some ideas for Jifty plugins that I thought I'd run by the list to
> see if anyone was already working on such things and to get some
> feedback on how bad these ideas might be. I've used Jifty to create one
> application for my company and that's worked pretty well. With a few
> additional tools, I think Jifty might be a good fit for a collection of
> similar tools we're currently gathering requirements for, but to become
> a good fit, Jifty needs a few more features.
> These are *ideas* of things I would like to implement if we were to
> choose the Jifty platform, but won't happen unless Jifty continues to
> look like a good fit and I actually get approval to build them. So here
> goes:

The short version is "Yes." The slightly longer version is "I'm dying
for these tools."  The ever so slightly longer version is "This is where
I've been going for quite a long time and we're finally near the point
where it's plausible."  Read on for the extended-play version.

> Model/Schema Builder Plugin:
> This plugin would provide additional functionality that would allow for
> the creation of new models and update of existing models from within the
> application. You would create a new model, be able to set up some of the
> basics, and build out the columns of the model from within the screens
> provided by the plugin.

Yep. Makes total sense. I'm actually working with Audrey and clkao this
weekend on some core refactorings that will make this more plausible.
One thing we're doing is making virtual types based on sets of
validators, canonicalizers, storage plugins and data types. We're also
starting to look at breaking out all of those things into their own
classes, so you end up with a library of possible choices when building
columns.  This gets you the ability to specify basic behaviours without
writing any code.  One of the challenges is going to be representing
model classes as data, rather than code. But we're headed in that

> The goal would be that an authorized user would be able to visually
> develop models for the application. I can see some challenges regarding
> when to deploy the schema and how to cope with a user that adds a
> column, removes a column, and re-adds the column with a different set of
> settings or something, but I think that these difficulties can probably
> be overcome.

Well, that's no different than in regular traditional jifty apps. And
we've got support for on the fly upgrades like that.

> Action/Form Builder Plugin:
> This is a compliment to the plugin above. This extends a similar visual
> tool to the development of custom forms. The actual action taken by the
> forms would either be limited to the built in
> Create/Update/Delete/Search functions or have to be implemented in the
> old-fashioned way (or have additional built-ins made available). 
> The goal would be that an authorized user would be able to visually
> develop forms for the application. I see fewer challenges with the
> implementation of this plugin than with the Model/Schema Builder, but
> there probably are some that my quick considerations haven't stumbled
> upon.

Again, the difficulty is really in serializing this stuff as data rather
than code, but we're looking at some of it from the other end this
weekend. HLB is working on a generic set of layout markup that will
allow drag and drop positioning and layout. He comes from the UI side,
so we're definitely going to need help on the backend making the tools
to actually turn layed out ui into jifty templates. It's worth looking
at the template-declare branch of jifty and Template::Declare itself, as
we're looking in that direction for something serializable and
introspectable.  HLB's even got some ideas about transforming this stuff
to both HTML and XUL to allow "desktoppy" applications on platforms
where that's an option.

> I have a few others I'd need as well, but I'll stick with just the two
> most important ones first.
> As you can probably tell from the plugins, I'm trying to make Jifty
> development more accessible. Here's why: I work for a general consulting
> firm and the consultants (CPA/MBA/HR types) would like to be able to
> build out form-based tools to help them during their engagements. Jifty
> is very close to providing the write feel for what they want for some
> simple data collection and reporting, but they really want something
> that they can tweak a bit. 

The one thing you don't need to do is sell me on why this is desirable
> The fact that Jifty's schema is so flexible makes this look like a good
> idea rather than trying to develop my own schema system by creating a
> generic set of "object" tables with "field" rows associated with them
> according to some "custom field" table defines things (i.e., how RT
> handles custom fields). There are some existing web services for doing
> similar things as well, but I've not found one that I'm happy with yet
> (but maybe I'm just picky). I'm also looking for a challenge at work
> where I can make a solid contribution to an Open Source project, which
> is supported by my employer. This could be it.

Yep. It all makes total sense. And we really want to get there. Help
would be hugely appreciated.

> Anyway, this might be a terrible idea or someone might already be doing
> something similar, so I thought I'd let the members of the list help me
> out one way or the other. 

It may be a terrible idea, but we're already starting down the road
toward it, so we're at least compatibly crazy.

Welcome to our madhouse.


More information about the jifty-devel mailing list