Forum OpenACS Q&A: Bug or feature?

Collapse
Posted by Richard Hamilton on
My question relates to 'Edit-This-Page'.

I first noticed this in 4.6.3 when it caused me to have to drop the site and begin again(!@£&$*"^£%), and I have just installed ETP on a version 5.0 platform and I see the same potential for disaster.

The index page of ETP has a link (as should all descendent pages) to 'Edit parent page'. When I clicked this link it allowed me to put a page ABOVE the ETP root (i.e. at the openacs site root). What happens then is that if you add children to this new page, they appear as peers to the ETP instance (i.e. at the same level in the site-map tree as ETP).

Intuitively this seemed a little odd to me, as if they had broken their earthly bounds, but seemed to work OK to begin with. But when I tried to remove one I realised that ETP had screwed up the site-map good and proper!

Is this a feature or a bug. In other words should the 'Edit-parent-page' link be removed from the ETP instance index page?

Regards
Richard

Collapse
2: Re: Bug or feature? (response to 1)
Posted by Don Baccus on
Well, one might ask if ETP is a bug or a feature, I'm afraid :(

While useful and providing some slick, creative functionality that we use here on openacs.org ...

it is also true it totally ignores [Open]acs 4.x conventions and essentially creates its own world.  If you live within it, you're OK, but otherwise, well, you see the result.

It was written before community members really understood the [Open]ACS 4/x architecture, understandable since aD itself didn't.  It's no worse than some aD provided code from roughly the same era.

Hopefully we can improve it ...

Collapse
3: Re: Bug or feature? (response to 1)
Posted by Richard Hamilton on
Oh dear. Sorry I didn't realise that it was held in such low esteem.

Personally I rather like it!

Perhaps it would be safe to assume that it is not a good idea to allow edit this page to edit pages outside its instance root, so I will add this to the bugtracker and have a go at modifying it so that one cannot edit the parent of the instance root.

I don't see any value in being able to edit the parent of the instance root anyway. Since openacs 5 allows us to specify a redirect from '/' to anywhere (so for e.g. to '/etp/index'), and previous versions can be dealt with by putting the etp index.vuh in the '/' of the site. This provides all the flexibility needed in terms of adding subtopics and pages without the headaches of messing with other packages' database records.

Regards
Richard

Collapse
4: Re: Bug or feature? (response to 1)
Posted by Don Baccus on
The functionality is nice, it just doesn't use system pieces like the content repository properly, though bits of this are being fixed.  For instance mixing up content item and content revision in at least one context (that's been fixed).
Collapse
5: Re: Bug or feature? (response to 1)
Posted by Stan Kaufman on
Don, you raise a related question that has often been asked here but never clearly answered: so which package *does* use the CR properly? Since DaveB generally is viewed as Mr CR and he wrote ETP, I've presumed that ETP *is* a good example. Jade's docs provide a nice synopsis of Karl G's official docs leftover from aD, but there's nothing like poking the source. Which package is Worthy, in your view? I have an immediate need for this advice, since we're dealing with CR design issues right now in Assessment. Thanks!
Collapse
6: Re: Bug or feature? (response to 5)
Posted by Talli Somekh on
Dave maintains ETP, Luke Pond originally wrote it as a hack to get an fairly workable CMS into OpenACS4.

So it's certainly not a corrent CR app... that seems to be the Holy Grail at the moment.

talli

Collapse
7: Re: Bug or feature? (response to 1)
Posted by Caroline Meeks on
Aristoi is moving a site from ETP to a BCMS system this weekend.  We are trying to implement a UI with the ease of use of ETP with extensiblity of BCSMS.  The client is strong OACS supporter and is going to help us with tune the UI.  Hopefully we'll end up with something useful for others. More details and code once we launch.
Collapse
8: Re: Bug or feature? (response to 1)
Posted by Don Baccus on
Well the original CMS did ... Also Jun's worked hard on BCMS to make it a good CR application, though I haven't had time to go over his code in detail he and I exchanged many, many e-mails while he was writing it.

File storage is OK but isn't a generalized application.

Collapse
9: Re: Bug or feature? (response to 1)
Posted by Jun Yamog on
I think ETP is nice and simple.  Its also the package I learned how CR works together with file-storage.

I think each UI that presents CR in a different way is good.  The aim to properly and consistently use the CR.  So different packages may use the content items, without breaking the content item.

Deds is working on the bcms-ui-base... etp thing mentioned by Caroline.  So we should end up with a bcms-ui-base that should  be 5.x compatible, some ETP compatibility, etc.  As an interim for Dave's xcms (next ver of bcms-ui-base).  It is still encouraged that ETP bug fixes still continue.

While Deds was also working on bcms-ui-base, the issue of explicit sorting came again.  ETP has this feature to order items.  I used a similar method on bcms-ui-wizard, and did not implement anything for bcms-ui-base.  This is because I am still waiting for which solution to take, while creating bcms-ui-base and none the projects that time needed explicit sorting.  I just pointed out to Deds the code on bcms-ui-wizard which is heavily borrowed from ETP.  So in the end bcms-ui-base may still use the ETP tree_sortkey for sorting items explicitly.  Which is not good since this is the primary reason why ETP could not be ported to Oracle.  It is possible to use cr_item_rels or cr_child_rels order_n column.  I think this issue has cropped up and we should deal with this sorting issue.  Any thoughts of this?

One of the ideas I came up but did not implement is to make a navigation page content type.  And child relate the different content items to it.  The draw back is, we need a separate admin UI for it... more complexity.  The plus is, you can have any number of navigtion page with different sorting.

Collapse
10: Re: Bug or feature? (response to 1)
Posted by Deds Castillo on
Scott just fixed the sorting of children through a straight port of how ETP does it.  But I do agree that the child order should be kept in the cr as well. This should come in the future while improving BCMS.

One thing to mention here is that we took into consideration backwards compatibility with etp (for the moment) while doing stuff.  This means that mounting BCMS and pointing it to an ETP instance should work.

Once I'm done with stuff, I'll do a cleanup, remove cruft and give it to Jun for committing.  I've also been studying DaveB's code on xcms.  That's the way to go once it matures.

Collapse
11: Re: Bug or feature? (response to 1)
Posted by Dave Bauer on
On ordering, there should be a solution using cr_chil_rels for XCMS. The code is coming soon, I worked on getting it to install on 5.1 this weekend. Right now it requires some change s (backwards compatible) to the CR, so it probably will ultimately be compatible with OpenACS 5.2.