On 8/29/06, Nilson Santos Figueiredo Junior <[EMAIL PROTECTED]> wrote:
I was doing something like that, and using regexes, but then I had to have everything in one action so I decided to explore the chained stuff. Matt's clues really helped my by providing an non-trivail example to build from. What I like about the chain I ended up with is the "table-key-command" patern to the REST parameters.
===
OK, so maybe report is a minor misnomer. This bit of my app is the "Daily Production Status Report" which is put together by the oncall engineer each morning. Currently its a spreadsheet, but the boss wants it webbed. So I have view actions to display it, and add/update actions. So my base path is /dailystatusrpt followed by the date in YYYY/MM/DD form, which Identifies a specific day's report. I accept YYYY, YYYY/MM, and even no date. In that case, I produce a calendar view (Thanks Advent Calendar!!!) which shows a view of this month in year YYYY, month MM in year YYYY, and this month respectively.
The calendars have links to ...../view where a report already exists, and ...../add where one doesn't.
..../add creeates the report header record, which includes the presenter's name, but mostly exists to provide a foreign key to tie a list of "issues" together.
..../view shows the list of issues for the report. If the user has the proper roles, they will see the issue entry form, and edit links next to each issue. The form submits to
/dailystatus/rpt/YYYY/MM/DD/issue/add to save a new issue, and
/dailystatusrpt/YYYY/MM/DD/issue/{issue_id}/update respectively, and the edit link
calls /dailystatusrpt/YYYY/MM/DD/issue/{issue_id}/edit to fill the issue data into the form.
So after all that, I found that I has a couple of empty actions which were used to absorb PathParts, which correspond to the "table" , The actions that capture some args and look up that record, and then a "command" action that figures out what to do with the record, and which template to end up in. I like it.
Len.
--
[EMAIL PROTECTED]
On 8/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> sub base :Chained('/') PathPart('') CaptureArgs(0) {
> sub drpt : Chained('base') PathPart('dailystatusrpt') CaptureArgs(0) {
> sub view_drpt :Chained('drpt') PathPart('view') Args(0) {}
> sub drpt_year : Chained('base') PathPart('dailystatusrpt') CaptureArgs(1) {
> sub year_view :Chained('drpt_year') PathPart('view') Args(0) {}
> sub drpt_month : Chained('base') PathPart('dailystatusrpt') CaptureArgs(2) {
> sub view_month :Chained('drpt_month') PathPart('view') Args(0) {}
> sub drpt_day : Chained('base') PathPart('dailystatusrpt') CaptureArgs(3) {
> sub day_view :Chained('drpt_day') PathPart('view') Args(0) {
> sub create_drpt :Chained('drpt_day') PathPart('create') Args(0) {
> sub issue : Chained('drpt_day') PathPart CaptureArgs(0) {}
> sub create_issue : Chained('issue') PathPart('add') Args(0) {
I've never really used chained actions (except when experimenting with
it) because all the code I could come up with looked like this - which
are extremely confusing action definitions IMO.
I think chained actions would work a lot better if there was a way to
chain things in a more abstract way. So that, in this example, you
could have a single 'view' action which would handle all the cases and
the preceeding action would just populate the resultset accordingly or
something to that effect (of course, your reports may actually be
completely different, but in my own use cases it does make a lot of
sense). However, the current way is also useful in some usage cases,
so I think Catalyst should probably have two ways of chaining stuff.
Of course, there might be better was to achieve the same functionality
that I'm not aware of. For now, I need to forward things around and do
it a little backwards (e.g. /dailystatusrpt/view/2005/10/08). It's
kind of counter intuitive, but it works.
I was doing something like that, and using regexes, but then I had to have everything in one action so I decided to explore the chained stuff. Matt's clues really helped my by providing an non-trivail example to build from. What I like about the chain I ended up with is the "table-key-command" patern to the REST parameters.
===
OK, so maybe report is a minor misnomer. This bit of my app is the "Daily Production Status Report" which is put together by the oncall engineer each morning. Currently its a spreadsheet, but the boss wants it webbed. So I have view actions to display it, and add/update actions. So my base path is /dailystatusrpt followed by the date in YYYY/MM/DD form, which Identifies a specific day's report. I accept YYYY, YYYY/MM, and even no date. In that case, I produce a calendar view (Thanks Advent Calendar!!!) which shows a view of this month in year YYYY, month MM in year YYYY, and this month respectively.
The calendars have links to ...../view where a report already exists, and ...../add where one doesn't.
..../add creeates the report header record, which includes the presenter's name, but mostly exists to provide a foreign key to tie a list of "issues" together.
..../view shows the list of issues for the report. If the user has the proper roles, they will see the issue entry form, and edit links next to each issue. The form submits to
/dailystatus/rpt/YYYY/MM/DD/issue/add to save a new issue, and
/dailystatusrpt/YYYY/MM/DD/issue/{issue_id}/update respectively, and the edit link
calls /dailystatusrpt/YYYY/MM/DD/issue/{issue_id}/edit to fill the issue data into the form.
So after all that, I found that I has a couple of empty actions which were used to absorb PathParts, which correspond to the "table" , The actions that capture some args and look up that record, and then a "command" action that figures out what to do with the record, and which template to end up in. I like it.
Len.
--
[EMAIL PROTECTED]
In this specific case, there are a few things that might make this less convoluted, and I did have a couple of moments of "how do I express that?" but I think this is a nice powerful addition to our action arsenal.
If I had one wish to add to the wish list, it would be the ability to capture a variable number of args.
_______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
