Plans for 1.0.

[jonathangeiger]

The unstable branch has seen quite a lot of action lately and I just wanted to outline some of the plans I have for it in hopes of generating a bit of discussion.

Behaviors

These have pretty much been fully implemented. There are several callbacks available and the ability to add custom methods to both models and builders. Additionally, a model class and its correspondent builder class can utilize these callbacks themselves, in essence acting as its own behavior.

I've implemented a SoftDelete behavior as a test, and we have plans for an MPTT or ClosureTable Behavior. Any ideas for other useful behaviors?

The nice thing is that behaviors can be user-written and, should people like them enough, merged into core.

API Cleanup

All of the backward incompatible API changes have and will continue to be documented, however here are the major ones:

• There has been a slight overhaul to the query builder interface.
• Pretty much every class has been moved around so Jelly isn't polluting the global namespace as much.
• All of the input() methods are gone!

Validation

There is a bit of discussion on the Kohana issue tracker going on right now about removing filters from the Validate class. I think this is a wise decision, and Jelly will be following suit. In the future, filters will be used as callbacks that are called whenever data is set on a model.

Additionally, I am considering overriding the Validate class to provide a few key features:

• Allow callbacks to take extra arguments and be passed the current model by default.
• Allow rules and callbacks to use a callback like array(':model', 'method'), where :model is changed to the current model instance that is being validated. This addresses #86.
• Allow check() to be passed an array of data to be validated, so that we only have to instantiate a validate object once for a model. It will then be available in the model's meta object.

This should mean we'll have a cleaner fix for #13, as well as a proper way to implement Jelly_Field_File and Jelly_Field_Image. Which leads me to...

Image and File Fields

vitch and I have been working on finalizing these fields. However, in working on them I realized that doing the saving of the files in the field's save() method prevents validating the data properly (as outlined in #123).

The reworked validation model should allow the file saving part to be implemented as a callback that has access to the actual model (which is necessary for a few things).

Polymorphism and Inheritance

Banks has been working on this a bit, but has been incredibly busy lately. I may take this over to finish up his much appreciated work. I don't have a plan of action yet, so this is all I can report.

This and Behaviors were the two major features we wanted to get for 1.0.

Cleaning up fields

I think it's prudent to make some fields behave a bit more like SQL datatypes. The following properties will be added:

• allow_null Defaults to TRUE, as the SQL standard says. If TRUE, the default for the field will be NULL unless set by the user and NULL values will be allowed. If FALSE, the default for the field will be up to the field (Jelly_Field_String will default to an empty string, Jelly_Field_Integer will default to 0).
  • required Simply a shortcut to add a not_empty rule.
  • max_length Adds a max_length rule.

Minor Things

Besides what's been documented I also have the following plans:

• Fixes to select_column(). It's currently kind of broken.
• More tests (but I hate writing them).
• Documentation improvements (I enjoy writing this).

If anyone wants to help out or has any suggestions for improvement, now's the time.

[mintbridge]

For behaviors i think a versioning and/or a simple tracking would be useful. At the moment i extend Jelly_Model and override the save method so that any changes to a model are logged to seperate model so that i can easily see who(using Auth), when and what changed and also if needed restore old versions

[mintbridge]

i guess it could log to file if that was wanted aswell

[coreyworrell]

Everything is looking great. Just one thing I was thinking of (bc I know you like to keep the API flexible and user friendly) is remove select_column() and just use select_columns(), but use func_get_args(), and if an arg is an array good, if not just add it to the array of columns. $model->select_columns(array('some', 'columns'), 'other', 'columns'); I don't know who would actually do that, but it provides a way to use both styles w/out the extra function.

[dewos]

Hi! I just checked the behaviors code, and it's really look nice, great work! By the way, i still think that the ::query() method should be renamed ::factory() for consistence with kohana (and factory) style.

Jelly::factory('post')->select(); Jelly::factory('post', 1)->delete();

[banks]

By the way, i still think that the ::query() method should be renamed ::factory()

That would be counter -intuitive though because you are not building a jelly object. We have chosen to try to be consistent with query builder which uses DB::select() not Query::factory() or DB::factory(). The query() method is still a departure from this but I think it is sensible because it is much more semantic.

Regarding polymorphism, I have got the basics of STI working locally so I will try to find time this week to clean that up enough to merge into unstable and then Jon you can take a look and change it all ;).

[stensi]

Just wanted to say I'm really looking forward to 1.0. All the changes sound great! :)

I started converting my current project to use Jelly, instead of a customised version of ORM, but I think I'll hold off now until 1.0 due to the API and Validate changes (easier to convert it all once).

Am I being optimistic thinking 1.0 would be out by July?

[vitch]

This all sounds pretty good to me... The only thing that will prevent me from updating immediately will be the removal of the input() method. While I can see the sense in this approach, too much of my code will need to be rewritten to work without. I can of course override the base Jelly fields in my project and add the input() code back in which is what I will do for now (I had a quick play with Formo a while ago and it looks very nice but I thought that learning it and Jelly at the same time was too much so I decided to concentrate on Jelly and write my own form generation code using Jelly's ->input())

[jonathangeiger]

@stensi

Maybe a bit too optimistic. I'm still waiting on hearing back from the core team about what their plans for validation are. I've got a couple (at least 3) behaviors to write, polymorphism and STI (banks just contributed some code for that), tests, and documentation.

I want to take my time with this release and make sure I've done everything The Right Way. I'll make sure to keep everyone up to date though.

@vitch

I really feel bad putting input() in the first place. I can totally see how useful it is. The problem is that a lot people started asking for this feature or that feature tagged on to it and we really saw the potential for things to turn into a mess if Jelly started going the way of a Form/ORM hybrid.

My apologies for mucking up your work. As I said above, I'm going to take my time with this release and think through everything very carefully so this doesn't happen (fingers crossed) in the future.

[gerasim]

input() - a very handy tool. Do not delete if it already exists. :)