another rails route application idea
simcha
First I would like to say that I really like route and find your work
superb. I really like both the process DSL and the tool itself. At
work I use Adobe Livecycle BPM and Activia both come with packaged
task-manager or workspace. So looking for something like that I found
nice RoR example by Torsen. It is really interesting being all dynamic
and in browser development. But I thought that it can be also nice to
have something more traditional code on the disk like. So I made a
copy of Torsen application and made little proof of concept engine/
plug-in for rails based on it. The idea is to put process definition,
task forms and controllers and participants in proper folders in rails
app and have some glue code in the plug-in for rendering it and task
list and such. I have placed code on github https://github.com/simcha/rails_bpm
and if some of you are interested I would be glad to hear some
comments.
Thanks
Jan
John Mettraux
On Thu, Mar 17, 2011 at 08:43:21AM -0700, simcha wrote:
>
> The idea is to put process definition,
> task forms and controllers and participants in proper folders in rails
> app and have some glue code in the plug-in for rendering it and task
> list and such. I have placed code on github https://github.com/simcha/rails_bpm
> and if some of you are interested I would be glad to hear some
> comments.
Hello Simcha,
at first, sorry for the late reply, I was "on the road". Thanks for this nice proof of concept.
If I understood correctly, you have
app/participants
app/controller/tasks
app/views/tasks
that gather participants and task customizations.
You're also bringing generators to the table.
I have to say I like it a lot. Torsten told me (IRC) he will have some time tomorrow to have a look at it.
I was wondering if you wanted to continue maintaining this tool and if yes, how we could support you.
One small thing : ruote gets mispelled a lot to "route" ;-)
Thanks again, talk to you soon,
--
John Mettraux - http://jmettraux.wordpress.com
simcha
> at first, sorry for the late reply, I was "on the road". Thanks for this nice proof of concept.
> If I understood correctly, you have
>
> app/participants
> app/controller/tasks
> app/views/tasks
>
> that gather participants and task customizations.
> You're also bringing generators to the table.
example generator and install generator only.
> I have to say I like it a lot. Torsten told me (IRC) he will have some time tomorrow to have a look at it.
>
>
proper answer is yes I will continue the work but the amount of time I
spend on it will probably vary. As for the support I will have many
questions probably when it comes to more advanced functions. For now I
was implementing proper pagination to task list and encounter some
errors with :count handling in StorageParticipant. Created an issue in
github #22. For now paging will work after fetching all result, not a
big deal for alfa stage of a project we are in.
my best.
> Thanks again, talk to you soon,
simcha
>
> --
> John Mettraux -http://jmettraux.wordpress.com
John Mettraux
On Tue, Mar 22, 2011 at 12:01:08AM -0700, simcha wrote:
>
> This is my hobby project I don't use Ruote at work _yet_ ;). So the
> proper answer is yes I will continue the work but the amount of time I
> spend on it will probably vary. As for the support I will have many
> questions probably when it comes to more advanced functions. For now I
> was implementing proper pagination to task list and encounter some
> errors with :count handling in StorageParticipant. Created an issue in
> github #22. For now paging will work after fetching all result, not a
> big deal for alfa stage of a project we are in.
Hello Jan,
it's fixed [hopefully]
https://github.com/jmettraux/ruote/issues/22
Feel free to re-open or to open a new issue if needed.
Many thanks,
simcha
Thanks for very quick fix :) It works fine, at least for me ;)
I made version with pagination and separate lists of tasks per user
and his/hers groups.
I found next issue on my way https://github.com/jmettraux/ruote/issues/23
but made and workaround so it is working for now.
Next things I am willing to implement are:
1. Issue claiming from group and realising back to original group.
2. Process versioning => here I am not sure how to do it. I am
considering use of suffix V1 , V2 in class names or asset names of
processes, participants and tasks. And to call them based on process
version number. On one hand it is not looking very nice on the other I
have no second idea. What you think?
3. Access control based on process.
4. Process history and auditing.
5. Some way to render buttons with answers like "yes" "no" instead of
"proceed" only.
Based on task definition in the process preferably.
6. Search in task list.
7. Way to schedule absences and to redirect tasks assigned to absent
user both based on schedule and manually by administrator.
Long list but some day...
Thanks
Jan
John Mettraux
On Thu, Mar 24, 2011 at 10:31:17AM -0700, simcha wrote:
>
> Thanks for very quick fix :) It works fine, at least for me ;)
> I made version with pagination and separate lists of tasks per user
> and his/hers groups.
> I found next issue on my way https://github.com/jmettraux/ruote/issues/23
> but made and workaround so it is working for now.
Hello,
many thanks for the issue, I will take care of it tomorrow hopefully.
> Next things I am willing to implement are:
> 1. Issue claiming from group and realising back to original group.
> 2. Process versioning => here I am not sure how to do it. I am
> considering use of suffix V1 , V2 in class names or asset names of
> processes, participants and tasks. And to call them based on process
> version number. On one hand it is not looking very nice on the other I
> have no second idea. What you think?
you can do
Ruote.process_definition :name => 'x', :revision => '1.0b' do
end
and then
RuoteKit.engine.processes.each do |pr|
puts "#{pr.definition_name} #{pr.definition_revision}"
end
> 3. Access control based on process.
> 4. Process history and auditing.
https://github.com/jmettraux/ruote/blob/440dc90d4b88ee8ba4de5340b5c7de2f8c34dd75/lib/ruote/log/default_history.rb
https://github.com/jmettraux/ruote/blob/440dc90d4b88ee8ba4de5340b5c7de2f8c34dd75/lib/ruote/log/storage_history.rb
> 5. Some way to render buttons with answers like "yes" "no" instead of
> "proceed" only.
> Based on task definition in the process preferably.
Many many possibilities here. One small example:
https://github.com/jmettraux/quaderno
> 6. Search in task list.
Ruote::StorageParticipant#query
> 7. Way to schedule absences and to redirect tasks assigned to absent
> user both based on schedule and manually by administrator.
>
> Long list but some day...
Good luck !
Kind regards,
simcha
Thanks for the tips.
With process versioning the problem is that new process versions tend
to need new task forms and new participants while the old process
versions are still running and need the old ones. So using :revision
as you say is only a beginning. The question is how to version tasks
and participants. From development point of view suffixing classes has
such an advantage that you just copy your class on the beginning of
the work leaving old version intact. Adding version as an argument
would give us nicer code but bring high possibility of braking old
processes.
For rendering "yes" "no", I did not make clear what I mean. I would
like the task definition in the process to contain sth. like this:
junior, :task => "fix pipe", :answers => "fixed, not fixed"
senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
And render "fixed", "not fixed" buttons in place of "proceed" button.
I now how to do it technically. But my questions are: Was it done
before? If yes, are there some custom names and format for that? If
not do you like the names provided here?
Hope this time it is clearer.
I managed to implement claim, no errors found this time sorry ;)
All the best,
Jan
On 24 Mar, 20:03, John Mettraux <jmettr...@openwfe.org> wrote:
> On Thu, Mar 24, 2011 at 10:31:17AM -0700, simcha wrote:
>
> > Thanks for very quick fix :) It works fine, at least for me ;)
> > I made version with pagination and separate lists of tasks per user
> > and his/hers groups.
>
> Hello,
>
> many thanks for the issue, I will take care of it tomorrow hopefully.
>
> > Next things I am willing to implement are:
> > 1. Issue claiming from group and realising back to original group.
> > 2. Process versioning => here I am not sure how to do it. I am
> > considering use of suffix V1 , V2 in class names or asset names of
> > processes, participants and tasks. And to call them based on process
> > version number. On one hand it is not looking very nice on the other I
> > have no second idea. What you think?
>
> you can do
>
> Ruote.process_definition :name => 'x', :revision => '1.0b' do
> end
>
> and then
>
> RuoteKit.engine.processes.each do |pr|
> puts "#{pr.definition_name} #{pr.definition_revision}"
> end
>
> > 3. Access control based on process.
> > 4. Process history and auditing.
>
> https://github.com/jmettraux/ruote/blob/440dc90d4b88ee8ba4de5340b5c7d...
John Mettraux
On Thu, Mar 24, 2011 at 11:22:23PM -0700, simcha wrote:
>
> With process versioning the problem is that new process versions tend
> to need new task forms and new participants while the old process
> versions are still running and need the old ones. So using :revision
> as you say is only a beginning. The question is how to version tasks
> and participants. From development point of view suffixing classes has
> such an advantage that you just copy your class on the beginning of
> the work leaving old version intact. Adding version as an argument
> would give us nicer code but bring high possibility of braking old
> processes.
Hello,
you're right, but remember that participants (and forms) are sometimes meant to be shared among workflows.
Of course, versioning the set { workflow, participants[, forms] } is a valid solution, there will probably be some duplicates (things that do not change but are still present in the new revision).
Until now, I always worked with processes that changed faster than participants. And participants shared among processes.
This is not directly related, but it could provide some inspiration :
app/forms/{workflow_name}__{workflow_revision}__{task}.haml
app/forms/{workflow_name}__{task}.haml
app/forms/{task}.haml
app/forms/default.haml
It's a scheme for looking up forms in Rails. There is only one human participant which loads forms starting with the most detailed path. As soon as it finds a form, it uses it. default.haml matches always (catch all).
You could think of such a scheme for automated participants
app/participants/{workflow_name}__{workflow_revision}__{participant_name}.rb
app/participants/{workflow_name}__{participant_name}.rb
app/participants/{participant_name}.rb
app/participants/default.rb
(I wonder if I shouldn't provide such an automated participants out of the box, it's very easy to implement... But it becomes a bit harder to manage for multiple workers on multiple hosts, you have to make sure the participants/ folder is in sync)
> For rendering "yes" "no", I did not make clear what I mean. I would
> like the task definition in the process to contain sth. like this:
> junior, :task => "fix pipe", :answers => "fixed, not fixed"
> senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
>
> And render "fixed", "not fixed" buttons in place of "proceed" button.
> I now how to do it technically. But my questions are: Was it done
> before? If yes, are there some custom names and format for that? If
> not do you like the names provided here?
> Hope this time it is clearer.
No, there is no convention for this. Feel free to choose a solution you like.
I always thought that
sequence do
junior, :task => "fix pipe", :answers => "fixed, not fixed"
senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
end
could be reduced to
sequence do
junior, :task => "fix pipe"
senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
end
for greater readability and no loss in understanding.
Of course, if you rely on :answers to build forms, you cannot drop it.
Thanks for the exchange, best regards,
simcha
On 25 Mar, 08:51, John Mettraux <jmettr...@openwfe.org> wrote:
> On Thu, Mar 24, 2011 at 11:22:23PM -0700, simcha wrote:
>
> > With process versioning the problem is that new process versions tend
> > to need new task forms and new participants while the old process
> > versions are still running and need the old ones. So using :revision
> > as you say is only a beginning. The question is how to version tasks
> > and participants. From development point of view suffixing classes has
> > such an advantage that you just copy your class on the beginning of
> > the work leaving old version intact. Adding version as an argument
> > would give us nicer code but bring high possibility of braking old
> > processes.
>
> Hello,
> you're right, but remember that participants (and forms) are sometimes meant to be shared among workflows.
>
> Of course, versioning the set { workflow, participants[, forms] } is a valid solution, there will probably be some duplicates (things that do not change but are still present in the new revision).
>
> Until now, I always worked with processes that changed faster than participants. And participants shared among processes.
>
> This is not directly related, but it could provide some inspiration :
>
> app/forms/{workflow_name}__{workflow_revision}__{task}.haml
> app/forms/{workflow_name}__{task}.haml
> app/forms/{task}.haml
> app/forms/default.haml
>
> It's a scheme for looking up forms in Rails. There is only one human participant which loads forms starting with the most detailed path. As soon as it finds a form, it uses it. default.haml matches always (catch all).
>
> You could think of such a scheme for automated participants
>
> app/participants/{workflow_name}__{workflow_revision}__{participant_name}.rb
> app/participants/{workflow_name}__{participant_name}.rb
> app/participants/{participant_name}.rb
> app/participants/default.rb
>
> (I wonder if I shouldn't provide such an automated participants out of the box, it's very easy to implement... But it becomes a bit harder to manage for multiple workers on multiple hosts, you have to make sure the participants/ folder is in sync)
implement participants one is in app/participants and other in process
defining class. Now I am afraid that names of participants can easily
be duplicated by accident in the second case. So registering
participant with process_name and process_version (or as you say
workflow and revision) would make it safer. I really like the idea of
automated participant and task as for duplicates one can use class
inheritance to stay DRY. You are right that processes tend to change
faster than participants (not task forms thou) so I would suggests
changing your auto discovery list a little:
["workflow_name","workflow_revision", "participant_name"]
["workflow_name", "participant_name"]
["workflow_revision", "participant_name"]
["participant_name"]
catch_all
In this way we have shared version for many processes. One weird thing
however is that the number is of a process version and developers need
to remember that but they can always escape to
["workflow_name","workflow_revision", "participant_name"] if needed.
Still I'm not sure if it isn't to strange.
> > For rendering "yes" "no", I did not make clear what I mean. I would
> > like the task definition in the process to contain sth. like this:
> > junior, :task => "fix pipe", :answers => "fixed, not fixed"
> > senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
>
> > And render "fixed", "not fixed" buttons in place of "proceed" button.
> > I now how to do it technically. But my questions are: Was it done
> > before? If yes, are there some custom names and format for that? If
> > not do you like the names provided here?
> > Hope this time it is clearer.
>
> No, there is no convention for this. Feel free to choose a solution you like.
>
> I always thought that
>
> sequence do
> junior, :task => "fix pipe", :answers => "fixed, not fixed"
> senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
> end
>
> could be reduced to
>
> sequence do
> junior, :task => "fix pipe"
> senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
> end
>
> for greater readability and no loss in understanding.
>
buttons in a task form, not in the process.
> Of course, if you rely on :answers to build forms, you cannot drop it.
>
> Thanks for the exchange, best regards,
Jan
John Mettraux
On Fri, Mar 25, 2011 at 11:07:55AM -0700, simcha wrote:
>
> ["workflow_name","workflow_revision", "participant_name"]
> ["workflow_name", "participant_name"]
> ["workflow_revision", "participant_name"]
> ["participant_name"]
> catch_all
Hello,
then what about
---8<---
["workflow_name","workflow_revision", "participant_name"]
["workflow_name", "participant_name"]
["participant_name", "participant_revision"]
["participant_name"]
catch_all
--->8---
?
Best regards,
simcha
publish, :ver => '1'
Don't know witch is better. I'm not sure if this is more consistent.
When you have this ver in process definition than to be consistent we
need:
["workflow_name","workflow_revision",
"participant_name_and_optionally_revision"]
["workflow_name", "participant_name_and_optionally_revision"]
["participant_name_and_optionally_revision"]
throw error when participant_name exist in any stage before but
revision not, or am I wrong?
catch all
By the way I could not reopen issue 23 (don't know how to do it) so I
added a comment https://github.com/jmettraux/ruote/issues/closed#issue/23/comment/918141
Regs,
jan
John Mettraux
On Fri, Mar 25, 2011 at 11:57:55AM -0700, simcha wrote:
>
> Yes but than you need to put it somehow in the process right sth like:
>
> publish, :ver => '1'
>
> Don't know witch is better. I'm not sure if this is more consistent.
> When you have this ver in process definition than to be consistent we
> need:
>
> ["workflow_name","workflow_revision",
> "participant_name_and_optionally_revision"]
> ["workflow_name", "participant_name_and_optionally_revision"]
> ["participant_name_and_optionally_revision"]
> throw error when participant_name exist in any stage before but
> revision not, or am I wrong?
Hello,
you're right, let's get back to your initial idea. I will implement something tomorrow.
> By the way I could not reopen issue 23 (don't know how to do it) so I
> added a comment https://github.com/jmettraux/ruote/issues/closed#issue/23/comment/918141
I re-opened it by myself (the "actions" drop down on the top left).
Many thanks,
John Mettraux
>
> On Fri, Mar 25, 2011 at 11:57:55AM -0700, simcha wrote:
> >
> > Yes but than you need to put it somehow in the process right sth like:
> >
> > publish, :ver => '1'
> >
> > Don't know witch is better. I'm not sure if this is more consistent.
> > When you have this ver in process definition than to be consistent we
> > need:
> >
> > ["workflow_name","workflow_revision",
> > "participant_name_and_optionally_revision"]
> > ["workflow_name", "participant_name_and_optionally_revision"]
> > ["participant_name_and_optionally_revision"]
> > throw error when participant_name exist in any stage before but
> > revision not, or am I wrong?
>
Days fly.
I didn't forget you. Here is an initial implementation :
https://github.com/jmettraux/ruote/commit/9b8e943b1b1de0fc0834c1efda1a005d16575f59
It lacks #cancel, #accept? and co for now, but I should be able to add them soon.
Feel free to criticize, suggest, ...
Best regards,
John Mettraux
On Thu, Apr 07, 2011 at 01:05:55AM +0900, John Mettraux wrote:
>
> I didn't forget you. Here is an initial implementation :
>
> https://github.com/jmettraux/ruote/commit/9b8e943b1b1de0fc0834c1efda1a005d16575f59
>
> It lacks #cancel, #accept? and co for now, but I should be able to add them soon.
Hello,
I've made it complete :
https://github.com/jmettraux/ruote/commit/503d607c45fd59a3429f11cf045bbb9feb055f7f
Now I feel it lacks a way to express things like >= or ~>, it's only = for now (stealing rubygems/bundler language).
simcha
I had busy week I will try to use this tomorrow and report back.
Best regards
Jan
On Apr 9, 6:26 pm, John Mettraux <jmettr...@openwfe.org> wrote:
> On Thu, Apr 07, 2011 at 01:05:55AM +0900, John Mettraux wrote:
>
> > I didn't forget you. Here is an initial implementation :
>
> > It lacks #cancel, #accept? and co for now, but I should be able to add them soon.
>
> Hello,
>
> I've made it complete :
>