NYCPHP Meetup

[Dan Cech]

It sounds like you really just need to change the way in_court is used, 
having multiple options instead of just yes/no.

Then your javascript can key off that and your users can create any 
event types they require and specify where they take place.

Dan

On 7/15/2011 11:30 AM, David Mintz wrote:
> I hesitate to bore you with my details, but -- you can stop reading if it
> gets too boring.
>
> The application will manage judiciary interpreters (yeah, same project for
> the past 8 years or so) in the office where i work ( as a court interpreter;
> code monkey isn't in my formal job description at all (-: ).
>
> There's an entity called an "event." Its attributes include: date, time,
> language_id, event_type_id, location_id, and so forth. Naturally, there's a
> related table called event_types for storing the kinds of things we do:
> plea; sentencing; arraignment; attorney/client interview; etc. There's much
> more to be said about the db design, but I'll skip it.
>
> event_types have an attribute "in_court¨ which is boolean. Things are either
> in-court, or they are ancillary events like attorney-client interviews.
> (This is important; the suits in Washington require federal courts to report
> interpreter usage based on such things).
>
> Fast forward to the user interface for creating/editing events. I want to
> intelligently guess the default location based on the event type. (A judge
> has a default courtroom usually, though in some cases not: some have only a
> default courthouse. My locations model supports one level of nesting. A
> courtroom is in a courthouse but both are locations.)
>
> Now we come to some Javascript: an event handler that fires when the change
> event on the "judge" select element happens. This handler looks at the
> event_type to decide whether to set the location controls to that judge's
> default courtroom, or not. I will have already loaded a JSON data structure
> that tells me if an event_type is in_court or out. (There's much more: e.g.,
> I get the judge's default location info via xhr and cache it; so first I
> look in the cache to see if it's already there. Yesterday I created a flow
> chart on a large marker board to get a clearer picture in my mind, and
> confirmed the obvious:  it seems complicated because it is complicated.)
>
> The plot thickens if the event_type is out of court. if it's out, it's
> usually still in a courthouse, so I want to leave what a call the parent
> location (the building, basically) consistent with the judge's default.
> Unless the event_type is of type "probation interview" which is almost
> invariably held outside any courthouse:  those happen in jails and US
> probation offices. Therefore, if the user selects "probation interview" I
> don't want to default to any location, but make her choose (note my PC use
> of what I call the counter-sexist "she." Actually everyone is my office is
> female except me, so the odds are that the user is indeed a she (-:).
>
> So, should my JS code examine the currently selected event_type option to
> see if it matches the string "probation interview?" That would do fine,
> unless a user with admin privileges decides to edit the name of that
> particular event_type beyond recognition and breaks my javascript. Hence my
> conclusion that this application needs to have certain event_types -- I
> think of them as "core" event types -- that are loaded into the database at
> setup time and are never messed with again. There's a logical business basis
> for that:  there are certain kinds of courtroom events that you are
> absolutely going to need, so why not get them in there up front. Thereafter,
> users at a certain privilege level can add other event types as needed --
> occasionally some new exotic thing may arise; edit them when they decide
> they spelled it wrong; delete them (if the event_type has no related rows
> and they change their mind).
>
> I don't think it makes sense to have two different tables, as in "basic"
> event_types that ship with the app, and "custom" that the user creates. That
> would make for torture when it comes time to figure out which table you need
> events to JOIN with.  btw I have seen db designs in which you had a column
> for a foreign key, and another column to tell you which damn table to FK
> pointed to. Obviously this is for myisam or similar, not db-level FK
> relationships. I think that's a bad idea and don't wanna do that (again (-:
> )
>
> Better, it seems, is to somehow mark my sacred rows as such. At the UI level
> I simply won't provide a way to edit them. At the model level I will throw
> an exception if they try to update|delete them. So I'm planning to add a
> boolean "mutable" to my event_types for that purpose. (Pseudo-boolean, if
> you will, since this is MySQL).
>
> PS:  My weapons of choice are MySQL, Zend Framework, and JQuery. When it's
> all done, this will be far and away the most ass-kicking federal court
> interpreter management application known to humankind.
>
> Comments?
>
>
>
>
>
>
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation