Re: [Openinteract-dev] Document Review implementation questions

[Andrew H. <hu...@ll...>]

At 12:19 PM 7/25/2003 -0400, Chris Winters wrote:
>Andrew Hurst wrote:
>>   I'm just about to start work on the changes I've been mentioning this 
>> week, and I have a couple questions before I begin.
>>1. I noticed in the TODO for the comments package you list "resist 
>>feature creep" :)  Should I fork another comments package from that 
>>(maybe call it comments-creepy) that includes the changes I've mentioned, 
>>topics for comments, comment default security, etc.?
>
>I think creating another comments package is a good idea. (I dunno about 
>'comments-creepy', but that's your perogative :-)
I'll think of a better name.  -creepy was a reference to feature creep, and 
rather tounge-in-cheek... ;)

probably rich-comments unless there are objections.

btw, other features for comments I don't think I mentioned.  A security 
level to be able to post comments as anyone.  Ability to append to 
comments.  Ability to delete comments.

>BTW, what do you mean by 'topics for comments'?

When they post a comment, it will be attached to a section of the 
document.  Their comment will cover one of four topics, "Text to Append", 
"Text to Replace", "Question on Text", "Issue or Counterpoint".  When they 
reply, they want to have 4 other topics to choose for the comments: 
"Accepted as Text to Append", "Accepted as Text to Replace", "Response to 
Question", "Response to Counterpoint".  Personally I think that the review 
comment topics are redundant, as threading will take care of the topic 
implicitly.  But I'm still working on that battlefront.

Thus I was thinking of adding in topics just like story sections.  Doesn't 
look too hard to do.

>>2. Would you rather me modify the news package to allow uploaded files 
>>and paginate the articles or would you rather have a basic 'document' 
>>package, that would have the features mentioned before (splitting into 
>>parts based on html, uploading files, etc.).  I'm leaning towards the 
>>latter, since it would allow an easier 'all-in-one' interface for editing 
>>a document all at once, or editing an individual part, etc.
>
>The 'base_page' package does some of what you're mentioning. You can edit 
>HTML/text documents through the browser or upload documents (and replace 
>them) as well. IIRC it has a rough (and possibly undocumented) pagination 
>scheme too, but it's been a while.

Cool.  I was thinking I was going to end up taking a little from each of 
those to end up with the final product.  Thanks for the pointer.  If 
base_page already includes pagination, I might just fork that, I don't 
think all of the modifications that I've suggested should go in the base 
package.  Though... the more I think about it I'm not sure I have to make 
that many modifications if it already supports pagination, etc.  The 
biggest thing is being able to globally mark a document as frozen, for no 
more comment posting and modifications, and a way to see it all at once 
with comments in-line.  The latter sounds like an added action, and the 
former sounds like its already in there, if not a useful feature by 
itself.  Also an easy ability to delete the whole document (each page as 
well) all at once.

>>3. When I worked on Scoop we had a var (essentially a feature toggle, on 
>>or off if you want it enabled) for everything under the sun, configurable 
>>through an admin interface.  I've noticed no real such thing in OI, other 
>>than the action.perl and server.ini files.  I was thinking that the 
>>comment topics should be able to be turned on and off, I don't think that 
>>everyone would need that.  Any suggestions on where to put this flag?
>
>Probably the best place for it would be the global override configuration 
>file. This is a file that remains untouched by package upgrades but is 
>still able to modify them. For instance, I could have something like:
>
>[myaction mytoggle]
>task  = add
>value = yes
>
>(I can't remember the exact syntax, but I think the 
>OI::Config::GlobalOverride module might be documented... I can fill in 
>details later if you like.)
>
>You could have people modify this directly or create a web interface for 
>it, with the caveat that the web interface changes won't take effect until 
>a server restart.

I'll do that.

>(Is that how Scoop handles such changes?)

Scoop had a vars database table, that was loaded into a memory cache on 
server startup.  You could edit everything you wanted, and it took affect 
over the whole server immediately.  With every request a single query to 
the db was run that checked if the cache in the child was out of date (the 
latest update time was stored in the db).  If so it reloaded the vars, if 
not it didn't.

Have you ever run Scoop?  If you want to check out the admin interface 
create an account on scoop.kuro5hin.org and I'll give you admin access for 
a bit to poke around.  Its got some neat features.

by the way, regarding development of packages, is this the standard cycle?
make modifications in package directory
remove package from site
remove package sql from db
re-apply package to site
re-apply package sql
restart apache

with the sql steps possibly being skipped.  I noticed the scripts on the 
webpages but I haven't had a chance to check them out fully yet.  Still got 
a few "ASAP" VB Scripts first... :-(

Thanks for the input
-Andrew


>Later,
>
>Chris
>
>--
>Chris Winters (ch...@cw...)
>Building enterprise-capable snack solutions since 1988.
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>openinteract-dev mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openinteract-dev