Thank you for your response! > > > > I see. Does it mean I can plug in the admin interface provided by > ruote-kit > > in my web application? > > Yes. > > You can, for example, add this to your config/routes.rb: > > ---8<--- > # routes to RuoteKit > match '/_ruote' => RuoteKit::Application > match '/_ruote/*path' => RuoteKit::Application > --->8-- >
Got it. And since RouteKit is a Rack application, it can take it from there. Makes sense. > > > Can I configure views so that there is a consistency > > across the app? > > Yes, it's doable, it's Haml + CSS (and Ruby). > OK. > > Generally people use ruote-kit's interface as a special admin only zone. > When > they want to integrate in their core webapp, they look at ruote-kit for > inspiration and build their own views and controllers. > > I guess I will need to do something similar. > > > Yeah, trying to understand the choices that I should make. I do need to > > give (some of) my users an ability to modify process definitions, so an > > admin interface is required, I believe. > > Do you mean "modify process instances"? If you need to modify process > definitions, only a text editor is required. > Well, I meant process definitions. And that is the confusion I have. My understanding with dynamic workflow was that it is a process that is not fully determined at the time of initial creation and instead is defined (at least partially) at run-time. For instance, the user who created the process determines next steps after a checkpointing step has been reached. And it is this user who I termed as process administrator. I guess my terminology is wrong. Does such an interpretation of "workflow" make sense? Or does the process definition have to be usually determined a priori? > The admin interface is handy for administering the system, not really to > design process definitions. > I see. But since some of my users need to be given a web interface to create/modify the processes, it is important for me to do more than text editor? > > Maybe you meant modifying process instances and in that case, yes, the > admin > interface offered by ruote-kit is handy (for process administrators). > Process instances are modified by the actions taken by participants is what I thought I read, e.g. in the "getting started" example (which I ran), the state of process instance was modified when :alpha got a message and then passed it on to :bravo via the workitem. The process definition itself was fully determined -- a sequence of two participants, :alpha and :bravo. Am I not understanding it right? > > > > But then, I am assuming that I will > > do that using ruote abstractions. Additionally, Kenneth's blogpost gave > me > > an impression that making a commitment to implementing workflows in your > > application is a fairly heavy-weight decision and I was not sure if I > > should do that, given that at least initially, most of the decisions are > > going to be made by other users logging in to my application (there are > no > > multiple applications/services involved). Looks like I have deliberated > > enough and am leaning toward using ruote. > > It's still OK for you to go with simpler abstractions, business objects and > plain controllers that modify their states, simple business rules and no > workflow engine problems. > > It's true that ruote is heavy-weight. You shouldn't dive directly into > building something with it. Take the time to do a prototype, then you can > make the right decision. > > I'm not selling anything to you. As a fellow developer, it's my duty to > tell > you not to use ruote if it leads to too convoluted a sytem. > > That's what I am trying to assess. And though the complexity seems to increase with the use of ruote, what I am doing seems to be modeled corrected as a "process" or "business process". And going back and forth between ruote and state_machine confuses me even further. To make it somewhat more concrete, what I am trying to do is model a hiring process. Every company seems to have a process for it (e.g. phone screen(s) followed by technical interviews followed by HR interview, followed by background check and a negotiation phase ... and some of these are optional). Any applicant applying for a job at such a company would need to pass through this process. The process creator needs to assign actual users to certain roles (e.g. interviewer), schedule the interviews etc. And this is a typical process or it may needs to be modified from company to company (and that's why I need a proper user interface for the users who do that). My gut tells me that using workflow to model such a situation is the right way to go. Would you disagree? Is a state_machine (or a few of them) in a better position to capture the essence of this? Regards, Kedar > Best regards, > > -- > John Mettraux - http://lambda.io/processi > > -- > you received this message because you are subscribed to the "ruote users" > group. > to post : send email to [email protected] > to unsubscribe : send email to > [email protected] > more options : http://groups.google.com/group/openwferu-users?hl=en > -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
