Yep! Helps a lot.
You're already moving in the right direction... you have one-to-many
relationships defined for the CAR-User join, which is what you need.
You'll have getEngineeringUser() and setEngineeringUser() on the CAR
object when you call transfer.get("car.generalCar",carID). So you can
simply do somethign like this:
<cfscript>
EngUser = transfer.get("people.user",userID);
CAR = transfer.net("car.generalCar");
CAR.setEngineeringUser(EngUser);
// set the rest of the values for CAR here...
transfer.save(CAR); //also could use cascadeSave() if needed
</cfscript>
Later on, when you call transfer.get("car.generalCar",carId), you'll
have to use getEngineeringUser() to get the engineering user to route
the ticket to. If you're not into heavy services (which I'm not, so I
like this better) you could create a car.getNextRoute() function
which is responsible for examining ticket state and business rules
and determining who the next user is that needs to see the ticket. If
you're not into heavy domain objects and prefer keeing this stuff in
services, having a WorkflowService.cfc could be a winner, probably
the latter, something like WorkflowService.routeCar(CAR) which pings
the next user in line based on business rules and ticket state.
Using decorators here may be of assistance since you could easily
implement a setEngineeringUserID(userId) which takes the userID value
from the event, converts it to an instance of people.user and calls
setEngineeringUser(User), passing in the instance it just created.
I'm still undecided if I like the use of a getter to apply a
different value behind the scenes, but it's the only way to, for
example, bridge between ModelGlue's event.makeEventBean() function
when you're using relationships instead of simple values for the
objects in question. It works, and pragmatically that's all that
really matters
If you needed to guarantee that your objects are of the right roles
when you set them to the CAR instance, override setEngineeringUser
(User) in the decorator, have it verify that User.getRole() returns
the right value and then call getTransferObject().setEngineeringUser
() (only available inside decorators) or throw an error.
Beyond that, since your ticket has the properties for each user
defined already and your UI is doing the filtering for selecting
users that have the correct roles, all you really have to do is
convert the userID from the form into a User object and pass it as an
argument to the right setter (car.setEngineeringUser(transfer.get
("user",engUserId)), car.setManufacturingUser(transfer.get
("user",mfgUserID), etc.). This is either a controller-level task or
a service-level task, depending on how you have things set up, but
since your form has 1 explicit field per one explicit method on your
transfer object, there's really no reason not to be explicit about
getting form data into your model object. This is where having
setMfgUserID(form.mfgUserId) would be handy, especially if you're
using an automated bean populator like even.makeEventBean() in
ModelGlue.
I think that's about it... does that help?
J
On Nov 10, 2008, at 8:50 AM, Gavin Baumanis wrote:
>
> Hi Jared...
>
> Basically,
> I need to be able to assign a role to a user.
> and assign a userid for that role for a given "car" - read help desk
> ticket.
>
> There are several "steps" through the business rules - help desk
> ticket work flow.
>
> I.e. after being entered by customer support (step 1) - if it is a
> manufacturing fault it needs to go to the user assigned as the
> manufacturing dept rep for THIS ticket.
> The individual is chosen by drop-down list of users filtered by role
> for each of the work flow steps
>
> After this it might (or might not) go to the engineering rep for this
> ticket.... and so on...
>
> Thus the table for the "ticket" has 6 columns for storing the possible
> 6 users that might be assigned to THIS ticket - on its way through all
> the 8 disciplines of fault rectification that is used into the auto
> industry.
>
> Does this help?
>
> Gavin.
>
> On Nov 11, 1:25 am, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote:
>> OK, I have to ask a question about your "ISA" issue before I can
>> really answer it.
>>
>> What, specifically, are you trying to accomplish? Are you trying to
>> guarantee that the user returned by getEngineeringUser() actually has
>> a role ID that matches the correct value for an engineering user? Or
>> are you trying to create an easy way of going from a userID value to
>> a User object?
>>
>> The more I read and thought about what you were trying to do the more
>> I realized I needed a bit more info.
>>
>> Thanks,
>> J
>>
>> On Nov 10, 2008, at 8:18 AM, Gavin Baumanis wrote:
>>
>>
>>
>>> Hi Jared,
>>
>>> I think your 30 minutes are well and truly up! ;)
>>
>>> None the less I look forward to your thoughts!
> >
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
"transfer-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
