Forum OpenACS Development: Admin abilities, handled on the same page, or on different pages?

1: Admin abilities, handled on the same page, or on different pages?

Posted by Jerry Asher on 08/09/03 01:39 AM

I am curious what the current thinking is on how admin abilities of a page are easiest handled these days?

OpenACS 3 typically featured separate admin pages "mounted" off of /admin.

ACS 4 seemed to prefer implementing admin features within the page itself (edit links) as well as having separate admin pages as needed (/mypackage/admin)

In a related evolution, ACS 3 featured separate pages that handled each step of a form. /bboard/reply /bboard/reply-confirm /bboard/reply-entry. In the meantime, "the web" seems to favor pages having each of these steps performed in the same page, usually implemented by passing a state variable along. It seems that OpenACS 4 forms seems to support this latter method. (Some folks seem to confuse this as the MVC approach.)

How complex are you finding developing applications in this manner, where the same page has to fold in each phase of a form, along with changes to support differences in that form that an administrator would require?

I can see it being easier (less code copying, less code copies to maintain when there is a change), and being harder (more complex logic to maintain).

2: Re: Admin abilities, handled on the same page, or on different pages? (response to 1)

Posted by Jade Rubick on 08/09/03 01:47 AM

I think you've described it very well, Jerry. It is much harder and much easier 😊

ACS 3 was very straightforward, but OpenACS is a little more sophisticated. The tradeoff seems to be that it's harder to learn and debug. The advantage seems to be that there is less code to maintain, and some things work almost by magic

3: Re: Admin abilities, handled on the same page, or on different pages? (response to 1)

Posted by Tom Jackson on 08/09/03 02:29 AM

There have been some good arguments for the new ad_form method of doing things. I think three top reasons are:

New and Update data go through the same validation, since they are handled the same way.

Easy to get a basic form up and going.

Consistency of look/feel.

I think usage of ad_form is increasing. If you take the time to learn it, it will probably save you lots of time in developing.

Personally, I have taken a different approach. I have the feeling that building a form is difficult. There are a million different ways you can format forms, and it is hard to substitute tcl code for html. So as of yet, I haven't tried to generate forms through tcl code.

What I have done to simplify development is to handle the easier problem of inserting/updating/deleting data, that is the *-2 pages. My model allows you to design forms to handle any number of objects and to insert/update/delete in one step. Once setup, all that is required it to write the form with the correctly named inputs, and submit the form to a generic form processing script.

My approach is essentially undocumented, but it provides a different model for development.

4: Re: Admin abilities, handled on the same page, or on different pages? (response to 3)

Posted by Jerry Asher on 08/09/03 02:41 AM

Is this your query-writer approach, or something else?

5: Re: Admin abilities, handled on the same page, or on different pages? (response to 1)

Posted by Ola Hansson on 08/09/03 02:27 PM

Hi Jerry,

My approach has been to use ad_form (!) and try to take full advantage of its ability to fold the various steps (fill in, validate, confirm, submit) and modes (add, view, edit) into a universal tcl/adp pair for the particular object. The advantage of centralizing stuff clearly outweighs the disadvantage of increased complexity/readability, I think.

Furthermore, I try to combine its services to different user types by dynamically providing fields/functionalities depending on the user's privilege. This is (as you know) only possible if the page isn't living under /admin, since that would require that the user has a fullblown admin privilege on the package instance. Sometimes it is useful to have separate admin pages under /admin, though, but that's mostly because you may need a different UI for efficient admin of the package and not because you don't want to mix in admin functionality on user pages, IMO.

In the package we recently wrote (Curriculum) I found it convenient to put the "curriculum-ave.tcl/adp" page (the form for the "curriculum" object) under a /lib dir parallel to the /www dir (thus above the page root) and treat it as an <include> that is included from two separate places; /www/curriculum-ave.adp and /www/admin/curriculum-ave.adp. Rather than linking from the /admin pages to a *-ave.* pair living under /www, I moved this pair to /lib mainly in order to preserve the bread-crumb trail in the yahoo-style navigation in both /www and /admin.

I'd encourage liberal use of <include>s for other reasons as well. For one it makes it a snap to write portlets for dotLRN.

/Ola

6: Re: Admin abilities, handled on the same page, or on different pages? (response to 1)

Posted by Tom Jackson on 08/09/03 07:17 PM

I'm curious what the strategy is for debugging a multi-function/multi-state page? I mean once deployed and users start having problems, how do you figure out what is screwed up?

Jerry, I was talking about my query-writer. I should cut a new version for some of my recent improvements, unfortunately those don't include documentation.

Ad_form is a good choice at least in the fact that a bunch of eyes are looking at it. I think as more example code becomes available it will be an even better choice. The folks who are using it are making a lot of progress in this area, and they are willing to answer any questions when they come up.

7: Re: Admin abilities, handled on the same page, or on different pages? (response to 1)

Posted by Ola Hansson on 08/09/03 08:18 PM

Tom, I'd go about it the same way as with other Tcl code, I guess. Ask the user to describe what they did when something went wrong, what message they got (if any), what time it happened, etc., so that I could check the error log ... Then i would most likely put a debug statement in the relevant script and move it around trying to pin-point the problem. Of course, it gets trickier the more complex the code gets, but with sufficient commenting it shouldn't be impossible 😊.

Not to take anything away from Don, his ad_form is great, but, basically it's because the form builder is great to begin with ... Clever as it is, ad_form is primarily a wrapper and should "inherit" the functionality that the form builder is extended with. The core developers' eyes, at least, will probably be looking more at the form builder proper, than at the wrapper. But for the package developers that aren't yet familiar with ad_form I would suggest to study the api-documentation for ad_form and to check out Jon's tutorial (somewhere over at www.jongriffin.com).

/Ola

8: Re: Admin abilities, handled on the same page, or on different pages? (response to 1)

Posted by Jerry Asher on 08/09/03 10:42 PM

Thanks, I appreciate the insights.

I like the ad_form approach, if only because that appears to be the UI that much of the web is expecting these days.

I am a bit concerned though about complexity and fragility -- yesterday while playing around, I accidentally gave the wrong perm to the public (the perm ui starts off and defaults to admin), and suddenly all of the public could admin this page. That would be a bit less fragile if the admin page itself was in a /admin -- there would be more checks -- is this user a site/subsite/module admin, AND does this user have write/delete/admin perm on this object.

9: Re: Admin abilities, handled on the same page, or on different pages? (response to 1)

Posted by Don Baccus on 08/10/03 12:32 AM

Ola, I'm not the least bit offended, after all it is I that have insisted over and over again that 1) ad_form is just a wrapper and 2) you have to understand how the underlying form builder works to make effective use of ad_form for complex forms.

Jerry - one point not mentioned above is that self-submit forms make it easy to implement in-form error messages, much more user friendly than the old acs 3x paradigm of putting up a separate page that lists errors and suggests you hit the back button to fix them.

This is my major reason for preferring the self-submit paradigm for form handling. As a developer I feel like it is my job to deal with more complex code or development if the result is significantly more user-friendly than an alternative approach, and I believe in-form error messages to be an example of this.

10: Re: Admin abilities, handled on the same page, or on different pages? (response to 9)

Posted by Jerry Asher on 08/10/03 05:31 AM

Right Don, that's part of what I meant when I obliquely stated that it's the UI the web seems to prefer these days.

It's also seems to be the code control structure that a lot of java servlet/beanie things seems to favor too and that's good too for marketing reasons, if nothing else.