1
AFLSC
Don't Release RC2!!
  • 2002/1/26 13:22

  • AFLSC

  • Just popping in

  • Posts: 10

  • Since: 2002/1/6 1


With the forthcoming release of RC2, XOOPS developers are encouraging module developers to go to town, promising consistency with the final release. My concern is that this might be too early given that the metadata (content about content) aspect of XOOPS is still immature. I'm suggesting that at this stage a "wrapper" be introduced for all content which in addition to metadata, also builds an abstraction mechanism into content in XOOPS permitting greater code reuse and communication between modules. XOOPs is already moving in this direction, and perhaps I'll be surprised and find that RC2 has already taken steps in this direction.

Conceptually, we should be able to agree on a basic content class which all other content inherits from, adding its own attributes which specifically descibe that data. This is a design issue. We do not necessarily need to build this using classes given that PHP4 is still limited in its object-oriented qualifications. Basic attributes include a unique ID (across all content on a XOOPS site), its class ID, its creation timestamp, its author ID, a read count, the ID of the group who have permission to read it, etc. I think we can very quickly come to an agreement in what these basic attributes are.

Content also has "methods" which can operate on that data. Each piece of content knows how to display itself in various ways: sideblock, central pane, as a list member, etc. This is how I'd like to view modules. A review module is simply code that knows how to manipulate reviews. A users module is simply code that knows how to manipulate users, or rather user profiles. User profiles are content too. Perhaps a central number allocation module is also needed which ensures that all content (irrespective of its class) has a unique ID, irrespective of whether its a review, news or a user profile. There isn't a performance issue here, a module can simply ask for a block of unique ID numbers and work with them.

A list mechanism for content is also fundamental. Think of it as a bookmark list. Each user will have a collection of bookmarks: a list of users s/he frequently wishes to post messages to as a group, a list of favourite forum threads s/he is tracking, an archived list of news stories. When a user logs in it is a simple procedure to go through that users bookmarks and alter him/her when that content has changed, whether because one of his favourite authors has written a new article, a forum thread has been updated, or a calendar event they were "subscribed to" (ie bookmarked) has been cancelled. Users will want to share bookmarks, and manipulate bookmarks as a group. In fact we should probably think of bookmarks as content with a module to manipulate it.

Let's say I'm building my XOOPS site around a large database. In my case, a database of tens of thousands of films. I create a film module which wraps each piece of film content in a common XOOPS content wrapper. Additional information specific to film content such as release date, country of origin, etc, are stored in a separate database table but the common information for all site content (creation date, read count, etc) are kept in the common XOOPS content table. Yes, there are performance issues, but in database design one commonly breaks the information into separate tables. Conceptually, film content inherits from the basic content class in that it is assumed to have the same basic attributes and methods.

The next issue is metadata: content about content. When everything is content, basically we're talking about associations between content which could be implemented as a join file or by each piece of content having a bookmark list of associated content. A forum post, for example, would associate itself with various other pieces of content, all listed in the main content table, which may be a film record in a movie site, a species record in an endangered animal site, a book in a literature site, or a person in a sports site, etc. I would suggest two basic types of association across all content defined in the basic content class: primary and secondary. An advanced search could find all content (forum and news posts, etc) which are primarily about, say, Tom Cruise, without listing discussions of Mimi Rogers which mention Cruise in passing.

The issue arises here of the overhead for the user. My first get-out clause is that it is the responsibility of an editor to ensure that content is properly classified. Secondly, I suggest that content is created in a different way when you have rich classification. When I want to discuss Mr Cruise I go to the page about him where I see the list of all (primary) news stories, all (primary) forum posts and all (primary) calendar events, etc, ordered by date. When I add a forum post it is automatically associated with Mr Cruise. If I'm commenting on a post which is also associated with the Vanilla Sky content record then my post also "inherits" that primary association. I suggest an advanced Text Sanitizer also suggests other associations through a simple search of the main content table, perhaps only looking at the "title" attribute.

I'll make a list below of the attributes I'd like to see in the basic class below. I'd like to build in the concept that content can be fundamentally objective or subjective, at least in intent (for all your philosophers out there). I'd suggest that content defined as objective would need approval before posting and would be edited in Wiki-style. For simplicity, I don't include the attributes necessary for a versioning system,for rewinding changes, but that should be built into the basic content class. Same for multilingualism which I'll write about separately. And a user rating system should also be built in here, with perhaps higher rating new stories being included in the newsletter.

One important attribute across all content is a bookmark ID determing who has read access to that content. Default is everyone, perhaps represented by NULL. But this builds in a mechanism where I can annotate any content on a XOOPS site (be it a review, a news story, a calendar event or another user) which only I or my workgroup can view. One could imagine a workgroup having a private form discussion about a calendary event. "Workgroup" is a loaded word: also think about it as a "Buddy List" of friends planning a night out. Buddy Lists or Workgroups are essentially User Groups defined by the user: for administration purposes I'd suggest the user who defines the buddy group controls who can and cannot join the group. The same bookmark mechanism (since it's just a list of content IDs which may be users or any other content) could be used for a group to collect together a list of films they want to include in a book, or an individual to bookmark videotapes they own or want to buy: a longterm shopping cart.

So, what do we get here that's worth holding back RC2 (or at least an open call to module developers) for. 1) An advanced search mechanism which works across all content, whatever your site subject matter. 2) An organisational mechanism for all content by subject matter (primary and secondary association). 3) An advanced bookmarking system which works across whatever kind of content you have on your site. 4) A method of sharing content within user-defined groups. Please feel free to comment, however brutally. I'm not an experienced PHP coder but I include the attributes below as a starting point.

Wanted to post this before RC2 is released so forgive me for any inconsistencies, spelling mistakes, repetition, etc.

Stephen



APPENDIX

Basic Content Class Attibutes:

01) Unique ID

Unique for every piece of content on a site, whether it be a user profile, a calendar event, a review ... whatever. Unique because this allows any content to be associated with any other piece of content irrespective of class. This also allows bookmarks to hold mixed content.

02) Unique Class ID

I suggest here that Class ID is prefixed with the author's XOOPS.org membership number to ensure that this ID is unique across the universe of XOOPS sites. This ensures compatibility whichever modules one introduces to a site. Clearly there is an issue here when one calendar module is switched to another calendar module, but it should be simple for a site administrator to update this.

03) Author ID

Author is a User who is just content. Everything is content. I guess there is an argument to have this as a bookmark ID which lists a group of authors for collaborative content or where a number of authors have contributed over time. But I need to think more about how versioning affects this when one has Wiki-style editing

04) Parent ID

Here I'm not referring to inheritence but to the previous forum post. Since all content can be commented on, at least as personal annotation, this is built in here.

05) Child ID List

Again, this refers to follow-up posts. There is a performance issue here when it comes to annotation where hundreds of users may annotate the same news story. Perhaps annotation should be implemented with bookmarks "owned" by the user (and possibly shared with a group through the user's account).

06) Timestamp when Posted/Created

07) Timestamp when Modified

08) Primary Association ID List

The list of primary associations which is nothing more than a list of IDs. Perhaps best implemented as the ID of a Bookmark List in the central Bookmark Table. This allows for optimisation when hundreds of posts have similar associations. Again, this is an implementation issue which I'm not so concerned about in this post.

09) Objective/Subjective Status

Fundamental to content I believe. As stated above I'd suggest that "objective" content should be edited Wiki-style and need approval before being invisible to every user of a site.

10) Reader ID List

NULL means every can read this. Otherwise, it's a private piece of content for the author or a small group. Again, best to implement this as the ID of a bookmark content-type. This permits the content to be shared by a group which changes over time without updating every piece of content viewable by that group. Very often that list will have one member, indicating personal annotation.

11) Read Count

How many times a piece of content has been read

12) User Rating

I think read count is too primitive a measure of a content's worth, particularly when making qualitive decisions like whether to include a post in the newsletter. This also aids workgroups in rating the importance of a specific event, etc. Hmmm, I guess this means that the bookmark module is extended.

13) Maximum Length of Content Measured in Characters

I think it's useful to restrict the size of certain content, assuming content is as simple as a collection of characters. Even when it's not, as in a user profile, or generic database record, I think it's useful to have a description of that user or record in text. Here, or course, I'm thinking 16-bit Unicode and not being Euro-centric!

14) Language of content

Using ISO codes here. I need to think more about multilingualism along the same lines as a versioning system. Perhaps each Unique ID (1) should be extended with the language code and the version number...

15) Text

Again, I'm including it here for reasons given in (13). When this is very long as in an article, I'd suggest this should be the abstract of the article which one may like to include in newsletters and in links to the main content from other sites.

16) [Primary] Weblink Address

Again, debatable whether it should be here, but I think it should be built in for when one starts messing with SOAP, etc. This isn't necessarily (or even ideally) a link within one's own site. A forum post or a news piece will frequently be primarly around an article posted on another site. Optional.

17) Include in Next Newsletter

Determined by content type. Perhaps only modifiable by editors of the site.

18) Title

Almost forgot this. As in title of forum post, title of news story, etc. Very useful for the search mechanims and also for the Text Sanitizer to determine what other content to make associations with. But useful if alternate titles are also possible, even if not displayed here. Again multilingual system would allow other languages, but I don't want to go into that.

19) User Group List

Although not a rich enough system for classification or workgroups, it does have its very broad users. User Groups should make semantic sense. Hence a sports site has Football, Baseball User Groups, etc. Content can be restricted of only interest to a specific User Group (or several User Groups). Should be possible to display content only marked as members of the Baseball User Group, etc.

<small>[ Edited by AFLSC on 2002/1/26 13:29:43 ]</small>

2
Sircuri
Re: Don't Release RC2!!
  • 2002/1/26 15:56

  • Sircuri

  • Just popping in

  • Posts: 43

  • Since: 2002/1/3 1


I hope i don´t sound very stupid now. I´ve read the post 5 times now and i can´t get any clue about what you´re writing here?? what's your point? i don't get it. I hope this is al because my lack of "good" english.

It looks like you are trying to integrate the Active Directory idea of Microsoft Windows 2000 into a Content Management Tool. You want to be able track every post/comment/other content part across all the XOOPS websites.
And you are also referring to variables/data that already exist in the current implementation like the number of reads/ date and author stuff.

I really hope you can clearify your complete post, because i think there are more people around here who don´t understand the post. At least i don´t understand it or am i the only one after all?

3
netwize
Re: Don't Release RC2!!
  • 2002/1/27 4:28

  • netwize

  • Just popping in

  • Posts: 89

  • Since: 2002/1/20


i cant read more than 2-3 lines ..

so i cant understand anything.

btw: release RC2 NOW!!

best regards,
netwize

4
AFLSC
Re: Don't Release RC2!!
  • 2002/1/27 15:38

  • AFLSC

  • Just popping in

  • Posts: 10

  • Since: 2002/1/6 1


XOOPS is a step forward in terms of design and pehaps ease of use, but it is still a primitive content management system. Or rather it does a great job of managing the creation of content, but a lousy job at managing that content over time. XOOPS is only six weeks old but it's already difficult to find old forum posts and news items. If you're proposed XOOPS site is something very transient (you only care about this weeks film releases, you only care about this week's football results, etc), then perhaps older content doesn't have value in your site. But personally, I get very frustrated on many of my favourite sites that the same discussions come up again and again because finding old forum posts is so difficult. It's that old Hollywood anecdote that it's easier to reshoot something at great expense than find the film cannister in the basement. I've written elsewhere why Amazon is a good content management system, but Napster is a bad one. It's very easy to find a specific book review in Amazon, whenever it was written, because it's a CMS with metadata. Yes, it's built on a database, but what is a database but a CMS.

That's why at this early stage in its development, I'm suggesting an abstraction mechanism is introduced so that there is a consistent interface for all content that allows advanced applications to be built for any content. That mechanism also builds metadata (content about content) into the system. I also suggested a possible implementation (which can be improved upon), because a content abstraction mechanism is a little more difficult to get one's head around than a database abtraction mechanism, although both serve the same purpose. In the same way that a later move from one database to another would lead to a need to rewrite all XOOPS modules, so would a late introduction of core mechanisms to manage content. An abstraction mechanism and a wrapper system for all content, ultimately simplifies the work for all module developers because complicated applications can be written by the XOOPS time for a basic content class which can be "inherited" by all modules: I'm thinking of comparative rating systems, user and group-wide annotation of content, versioning so that one can rewind changes to a calendar event, a universal bookmarking system, etc.

XOOPS already demands more from a module developer than PostNuke, for example, in demanding that you have a basic understanding of object oriented programming, etc. If you demand a little more from module developers, such as understanding how a database abstraction mechanism work, there are further advantages. I'm suggesting that XOOPS demands a little bit more from its module developers. It's an exponential thing. I agree that it's a slightly different philosophy of content and content management systems: its based on a belief that meta-content is as important as content. I don't have the time or energy to make a XOOPS fork, I'm too busy managing my own content, but it is worth my time to propose the direction that CMS are heading which will give XOOPS, our modules and the content on our individual sites a longer life. You can agree or not agree. I've had one private message from somebody who understood the article and that's enough for the article to have been worth the time I took writing it; it's served it's purpose as piece of communicative content.

Stephen

Not Scandanavian, but a huge fan of the Norwegian school of object oriented programming philosophy.

<small>[ Edited by AFLSC on 2002/1/27 15:40:14 ]</small>

5
bob
Release RC2
  • 2002/1/27 16:38

  • bob

  • Just popping in

  • Posts: 8

  • Since: 2002/1/9 1


I just did a search on the term cms, which returned your current and past posts ordered by date, the subject and the date they were created. It was easy; I had no trouble finding them.

While I find some of your ideas admirable, the idea that XOOPS should remain in limbo until they are implemented is unrealistic and unpalatable.

While XOOPS holds out a lot of promise to me over, for instance, phpnuke and myphpnuke, I can't even develop customized themes for XOOPS as it stands, because the developers have said they are changing rules for creating themes.

If I can't customize it, and soon, I'm going to have to continue with the other nukes. Hey, I have business to develop and web sites to build. I can't sit around for months waiting on XOOPS and put them on hold.

I would venture to say that's the case for many of us. XOOPS promises to be the best tool around. To make good on that promise, the creators need to develop a usable, customizable version quickly.

I look forward with great anticipation to RC2

6
Kiwi-NZ
Re: Release RC2
  • 2002/1/27 16:47

  • Kiwi-NZ

  • Just popping in

  • Posts: 11

  • Since: 2001/12/26


i to must agree with bob:
Quote:

bob wrote:
If I can't customize it, and soon, I'm going to have to continue with the other nukes. Hey, I have business to develop and web sites to build. I can't sit around for months waiting on XOOPS and put them on hold.

I have stuck my site on hold waiting for the release of rc2. If it doesn't come out soon i'll be looking else where just so that i can get my site running.

7
AFLSC
Re: Release RC2
  • 2002/1/27 17:40

  • AFLSC

  • Just popping in

  • Posts: 10

  • Since: 2002/1/6 1


If XOOPS suits your purposes, by all means use XOOPS. It's a great content management system. I'm just suggesting that XOOPS has limits which could be easily addressed without adding much visible complexity. I don't really expect RC2 to be delayed. And I don't think anybody reading this should worry that it will be.

Stephen

8
Anonymous
Re: Don't Release RC2!!
  • 2002/1/27 20:30

  • Anonymous

  • Posts: 0

  • Since:


With the lack of developer comments here, i suppose they are either a lil shy because they might not know how to do what your suggesting? Which isnt specificly a bad thing...after all FB dosesn't even use ANY classes at all Or because they just dont wanna get into a heated disscussion right before RC2

If you have any...i suggest you let some links to tutorials or sourcecode loose.. so those that are lost with these principles can read up on em

9
AFLSC
Re: Don't Release RC2!!
  • 2002/1/27 21:15

  • AFLSC

  • Just popping in

  • Posts: 10

  • Since: 2002/1/6 1


First I want to draw attention to your message signature: "If it ain't broke, fix it."

Secondly, I'll use this opportunity to plug one of the most impressive books I bought last year:

New Riders' WEB APPLICATION DEVELOPMENT WITH PHP4.0:
http://www.newriders.com/books/title.cfm?isbn=0735709971

Hope this is on the bookshelves of all XOOPS developers. I also found a great book the other day: it's small, it's square, it's red and it was aimed at content developers, stressing the importance of classification, but I can't think what it was called.

Stephen

10
Anonymous
Re: Don't Release RC2!!
  • 2002/1/27 21:35

  • Anonymous

  • Posts: 0

  • Since:


What about the sig? ...its a joke

Secondly, i dont buy books, i learn by taking things appart, reading the manual, and online docs/tutorials ....thus the question

Thirdly, im not a XOOPS developer, and i still suck when it comes to classes and the stuff you where talking about :o)

Login

Who's Online

184 user(s) are online (115 user(s) are browsing Support Forums)


Members: 0


Guests: 184


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits