[jifty-devel] Questions about Jifty features

[Stéphane Alnet]

Hello,

Sorry for the long email. I'm new to Jifty and wanted to evaluate the
complexity of implementing some of the things I need in my application
before "making the move". I especially need:

(1) Adding constraints on SQL queries:

    I need to be able to filter the display and restrict the insertion
of the content of all Models based on which "group" a user belongs to
(groups are stored in the Model alongside the users). Some key SQL
tables in my model contain a "group_id/owner_id" pointer to the group
that owns subsets of records (it doesn't make sense in the model to
have all tables have an owning "group" because external dependencies
dictate what can be viewed/modified from that selected set of SQL
tables). I already have code that generates SQL fragments on-the-fly
to do cross-table constraints (for example, user A can see records
WHERE external_id IN (SELECT id FROM external_table WHERE group IN
(SELECT group FROM group_user WHERE user = $user)), etc.), but I'm
fine with using something better inside Jifty.

    Is this what RightsFrom implements?
    RightsFrom seems to only care about "users", not "groups", how
should I extend this cleanly to support "groups"?


(2) Implementing changesets:

    I need to provide the ability to do different things which end up
being basically the same thing:
    - Undo: must be able to reverse a change that was previously done;
    - Change Control / Policy reviews: a change done by an actor
(user) A may be subject to review by another user B (or a chain / set
of actors);
    - Timed changes: changes are applied at a given date and time (for
example for contractual reasons).

    The way I decided to implement this is to define what I call
"ChangeSet"s which basically record the changes that would have been
done in the database (which table and columns would have been
modified, what are the old and new values, etc.), and depending on the
result to be obtained (simple Undo, Change Control review, timed) will
(respectively) apply the ChangeSet immediately, after review, or at a
given time (controlled externally).

    In turn, a "commit" of a changeset generates an INSERT/UPDATE
using the "new" values in the ChangeSet (for create/modify), or
marking a record as inactive (for delete). Conversely an Undo
(reversal) of a changeset involves marking the record inactive (for
create), generating an UPDATE using the "old" values in the ChangeSet
(for modify), or marking the record active (for delete); etc.(*)

    To achieve this I need to be able to:

    (a) mark records in the database as active/inactive; only "active"
records should be visible within Jifty. My understanding is that the
simplest way to do add such a field is to create a Mixin and use it in
each model in my application (the mixin basically adds a boolean
"active" column, ..).

        How would I then filter the records avaible within Jifty?
        Is there a way to implement this within the mixin (i.e. drop
the record if "active is not true")?

    (b) replace the standard create/modify/delete in Jifty by versions
that implement the ChangeSet mechanism (except for private Jifty
tables and the changeset tables themselves).

        Would creating appropriate delete(), insert() and
update_record_value() in MyApp::Handle be sufficient?


(3) Hiding parts of forms based on a form field:

    I need to show different forms based on the value a user selected
in a field (for example I have a SQL table that store information for
different types of trunks; the parameters for each class of trunks are
independent; this is similar in spirit to PostgreSQL's INHERIT
mechanism). I've seen Jifty::Manual::PageRegions; but I'm not sure how
to use that kind of technics to bind a field (generated by Jifty based
on the Model) to showing/hiding a region on the web interface, or
forcing/disabling the validation of field in the Model.

        What is the proper way of implementing this?


Thank you if you read this far; thank you even more if you care to reply!
Stéphane


(*) I wrote a very preliminary outline of how this could work[1]. I
understand this could create inconsistencies if changesets are applied
out of order, so I'll need some code to deal with it and warn a user
before applying a potential problematic changeset, especially differed
ones. I also understand I would have to regularly "vacuum" records
which have been inactive for a while. (So I'll actually need a
"last_modified" column alongside the "active" column. etc.)

[1] http://carrierclass.googlecode.com/svn/trunk/home/www/lib/CCN/ChangeSet.pm


-- 
http://carrierclass.net/