Re: [cgiapp] How to split runmodes into different modules

[Michael Lackhoff]

On 31 Mar 2006 at 8:25, Michael Peters wrote:

  The only difficulty is, if you want a cross-sub-application connection not 
  by a link but through 
  a form submission. That was my problem the other day.
 
 Form submissions should be no different than links. You just point the
 form's 'action' attribute at the same url that the link would go to.

In a sense you are right, of course, but in a sense it is different. In my 
example I want to save 
a record and after the save show a menu page. If I used the menu runmode as the 
form 
action for the save (and several other actions that all come out at this menu), 
things would 
get really messy.

 It works just fine for our stuff, and it can get pretty big. If you want
 a working example, check out Krang (http://krang.sourceforge.net). It's
 one really big CGI::Application.

I downloaded it once but it was too big and complex for me to understand what 
is going on -- 
at least at that time. Perhaps I should have a fresh look.

Thanks,
Michael


-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
  http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] How to split runmodes into different modules

[Michael Peters]

Michael Lackhoff wrote:

 I downloaded it once but it was too big and complex for me to understand what 
 is going on -- 
 at least at that time. Perhaps I should have a fresh look.

Another one you could look at is Smolder
(https://sourceforge.net/projects/smolder). It's much smaller and
simpler than Krang, but... it means I'm tooting my own horn :)

-- 
Michael Peters
Developer
Plus Three, LP


-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
  http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [cgiapp] How to split runmodes into different modules

[Jesse Erlbaum]

Hi Michael  Michael -- 

 If you want
 a working example, check out Krang 
 (http://krang.sourceforge.net). It's
 one really big CGI::Application.

That's not true.  Krang is not one big cgi-app.  Krang is actually
composed of multiple, separate CGI::Application modules, each launched
via their own instance script:

htdocs/media.pl
htdocs/history.pl
htdocs/about.pl
htdocs/schedule.pl
htdocs/my_alerts.pl
htdocs/category.pl
htdocs/desk.pl
htdocs/story.pl
htdocs/media_bulk_upload.pl
htdocs/workspace.pl
htdocs/bug.pl
htdocs/debug.pl
htdocs/site.pl
htdocs/status.pl
htdocs/publisher.pl
htdocs/group.pl
htdocs/env.pl
htdocs/user.pl
htdocs/help.pl
htdocs/my_pref.pl
htdocs/desk_admin.pl
htdocs/contributor.pl
htdocs/login.pl
htdocs/template.pl
htdocs/list_group.pl

These separate applications are tied together (in some cases, very
tightly) to produce the effect of one big application, which is the
goal for any project, I imagine.  This is done through links, sessions,
centralized security, and clear-headed thinking.

I do strongly agree that Krang is a good example of the use of
CGI-Application.  (And I'm not just saying that because I helped design
it!)  We spent time to thoughtfully consider what run modes belong in
which applications, and how they should function together.

One example of what is possible with this architecture is the
add_message facility.  (This elegant system was designed by Sam
Tregar.)  By cleverly using sessions and a custom CGI-Application parent
class, the developer can easily send a message to another page, even
if that page is in another application.  For example, if you save a
story you are redirected back to your workspace with a message at the
top of the screen, Story XYZ saved.

I'm obviously a proponent of the organizational scheme Krang uses.  As
far as multiple instance scripts:  The idea is that each script
(really, each URL -- that is the main purpose of an instance script)
represents an entry point into a task.  You could type in the URL of the
instance script and begin a task.  It's a point of looser coupling.
IOW, the run modes *within* one CGI-App are more closely related to each
other than to a separate CGI-App.  This idea is core to the philosophy
of CGI-Application.  If you don't believe in this philosophy, I think
you might find that a server page system will work better for you.

One other note, on which I have been harping for years:  If you are
about to tell me that you can't have a separate instance script for each
application because your login system would have to be duplicated in
each application, then you're doing things wrong.  Authentication and
authorization belongs in Apache -- not in your CGI-App module.

TTYL,

-Jesse-


--
 
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
 

-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
  http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] How to split runmodes into different modules

[Michael Peters]

Jesse Erlbaum wrote:
 Hi Michael  Michael -- 
 
 If you want
 a working example, check out Krang 
 (http://krang.sourceforge.net). It's
 one really big CGI::Application.
 
 That's not true.  Krang is not one big cgi-app.  Krang is actually
 composed of multiple, separate CGI::Application modules, each launched
 via their own instance script:

I didn't mean it literally as one big CGI::Application based module. I
was actually trying to make a pun that loosely meant one really big CGI
application that uses CGI::Application. Maybe I should have used a
smiley or something to indicate my non-literal intent.

-- 
Michael Peters
Developer
Plus Three, LP


-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
  http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]