Hmmm, no idea how I missed the progression of this thread, considering I started it :)

In quick response to my comment about an application framework, if you think of modules as little applications (which they are) using the XOOPS "frame work" to accomplish certain aspects (Auth, DB access, Presentation handling) then I think you can see why I call it such. Yes I suppose it could be called a library, but a library is nothing without the applications that use it, XOOPS on the other hand can be used without any modules (I don't count the system module as it's part of the core).

<begin rant>
Comments on the system design:

Almost all "CMS" (really portal scripts) in the Opensource community right now "attempt" to follow the MVC (Model, View Controller) pattern in some way or another. XOOPS is loosely based on the Page Controller using a Template View to handle the View portion, Mambo is a Front Page Controller and while it also implements a Template View it does so much differently than Xoops. It uses PHP and not a template engine like Smarty. This to me makes perfect sense, since PHP is in fact a template engine or at least it was back in the early days of C. Just as PHP developed into its own full scripting language, so too is Smarty but the one crucial difference is Smarty needs PHP to interpret it. So we have Smarty->php->C, which is an unnecessary layer of processing. Is it really easier to learn Smarty than to learn basic PHP??? For a good read concerning templates, read thishttp://www.massassi.com/php/articles/template_engines/old/ . Now I'm off topic, let me get back on track.

In order for XOOPS to be a contender in the CMS realm, as Herko mentioned, it needs to completely separate the three layers (or 4 really if you consider the page controller). Right now there is far too much presentation logic contained in the Page Controllers of modules and other pages. The page controller should simply be the facilitator of input data from the user, relaying that to the Model layer (Business/application logic) and telling the View layer(presentation logic) that something has changed in the Model layer and it needs to update (i.e. refresh the screen with new data from the model). The model should not be concerned with the data it's receiving, nor the data it delivers, it should only be aware of itself, and in the case of web apps, the data access layer (which is part of the model, but in N-Tier systems considered a separate layer).

Once this is achieved, multiple View layers can be developed(XML output, RSS, HTML, XHTML, Print, PDF, etc etc) and multiple Data Source Layers (DB, XML, SOAP, Flat File) without any problems at all.

Moving back to the CMS functionality; as has already been mentioned, one of the most crucial points of a Content Management System (funny how the words really do explain it all) is, well, managing the content. This not only includes the ability to add and update, but also the ability to manage the flow of which the content is produced, and by whom. While Groups are a step in the right direction, these are still geared towards a portal system managing web surfers, not workflow.

While I could list a million "features" to add to make XOOPS that little bit closer to a CMS, I find myself now asking, "Are we asking too much"? Is trying to combine Portal functionality and classic CMS functionality simply creating a beast that's only half assed at both? Are we trying to be too many things for too many people?

For me, the answer is yes! And for that reason, I've decided to pursue other avenues to fill my need for Content Management, and continue to use XOOPS for Portal site (Something it's VERY good at, the best IMO).
</end rant>

On a side note, something needs to be done about the timeout times for login. Trying to do a long post like above, if you don't save it locally you lose it all since you get logged out during the creation. When you try to post you get "You do not have permission to post here" and get sent to the homepage, very frustrating if you don't already know this happens and lose 20 mins of typing. :)

Quote:

Ah yes... The holy grail of MVC design. Anyone wonder why it has not been done before? I mean, the seperation above is not a new concept.

The reason is the 90/10 rule. You can get 90 percent with 10 percent of the effort. That last 10 percent is a real @#$%^!

I am not dogging the plan, and everything is inching toward a "sharper seperation" as Mith put it. But it is much easier said than done. IBM WebSphere, IBM Lotus Domino, .NET, J2EE.... All had the same goals with much bigger backers. None deliver the goods. If XOOPS can... I will be very impressed. Again, not dogging anyone, just a realist.

PS - If you are banking on MS for a "standard compliant and open XML markup to Word data", I want some of what you are smoking! Microsoft's embrace and extend has not gone away. Besides, Open Office can do this now. I built a custom reporting system for Domino much along the lines of what you are talking about. Believe me, I is not a panecea.

JMass

I can see the point Draven is making. There is a difference between an ideal solution and an achievable one (more so in the resource limited arena of open source). What about a compromise that would travel down the road half way? Right now (IMHO) there is a clear need to separate the presentation layer from the rest. Xoops, and its fellow cms, have a clear handicap when coming from a design perspective. If a 2 layer approach were used, would that be a feasible goal for near future? To allow XOOPS to break free from its current constraints on the presentation layer would be a huge benefit to the community as a whole.

Following the one input, any output idea... how about having complex Content Objects that have many default variables and methods and can be rendered (and/or extended) by different modules? Things like Link(s), News item(s), Poll(s), FAQ(s), Block(s), etc could be rendered by the CMS from the original complex object. I know that this sounds too complex, but it would allow objects to represent logical entities of content, so that a contest would be an object with polls, calendars and forum, a given subject would be represented an object with links, some articles and frequent news, while another subject would be a poor object with a news item only.

Then you could have Object Versioning (logical, structural?), Content Versioning (data) and/or Output Versioning (interface?).

Thinking along today's limits, it would be like having a News item that can have Version Control but also be cloned and extented into a News item with Poll or downgraded to a Calendar Entry.

Another very interesting way to follow would be adding a R (for Relation) to CMS, so that keeping the current core/module OO system an universal object (content+functions?) API could be developed to allow module interoperability: News can pull Links (and visit_count++), FAQs can pull related Forum entries, Articles can present its archive using Calendar... all these can be done today, but there aren't even module APIs, so anything that relies on 3rd parties will eventually fail. It'd be possible to have "a dinamic page about X" with Links, News, Forum threads, Pics, Events and whatever by asking that each module only show it's entries (objects) that have Category OR Title OR KeyWord matching X (or its offspring)

edit: Sorry, I should learn to think before posting... or at least reading on MVC

edit again: the R could also allow richer links between objects, like parent or similar... or even provider and user (for interfaces).

When Phil, at frxoops forums, mentioned some Lodel capacities and Christian coming up with the link of this fossilized idea... I estimate that it could be interesting to "re-discuss" it and maybe webmasters and developers can share some insights into how (if) XOOPS could be used as an academic intranet.

Already experimented XOOPS in a academic institution, using Novell+Microsoft & Apple (still moving some stuff to open sources projects) where XOOPS ran with an important lack in doc management and publishing.


Quote:

>> More Lodel
>> And Servoo


Such feature is possible with XOOPS ?
- Tanks all.

Perhaps it is just my lack of education speaking here, and if it is, please forgive me. I've tried to understand the discussion above based on my limited experience and I think I got the gest of most of it. It seems to me that the KISS rule applies here.

I agree that seperation of presentation, application, and storage are important, and I too believe that this should be the route XOOPS takes eventually. IMHO, XOOPS itself should only be the the interpreter if you will, whereas 3rd party modules should provide the presentation and application layers.

I really don't see much wrong with XOOPS as it stands today. It is a fantastic [Portal | Framework]. I'd like to see the backend features modularized so that 3rd party replacements could be installed without posing a potential compramise of stability and security (Isn't this the direction XOOPS is going?).

I guess what I'm trying to say is that I think it would be a mistake for XOOPS to be anything more than just a framework that pulls together 3rd party modules and themes, and interfaces with the DB.

I'm more of a hardware guy than a software guy, so the analagy I'm thinking is that of XOOPS being like the motherboard of a computer. Without 3rd party add-ons like a processor (PHP), RAM (PHP & DB), A hard disk (DB), and a monitor (Templates and Themes), a motherboard is useless. Of course, what good are all these parts if there isn't some kind of processing to be done (Applications), with some kind of input from the user (Applications that recieve input from forms [Templates & Themes]).

Where the analagy comes in is that each individual unit is pretty well useless by itself, but when they're all plugged into the motherboard (XOOPS), it all works together. The motherboard simply acts as the interface for all the other stuff and performs some of the more menial low level tasks (taking input from applications and storing it in the DB or retrieving from the DB and passing to the Templating engine which passes to browser, the appearance of which is controlled by the theme).

Ok, maybe I've rambled on needlessly for nothing. I'm just trying to make sense of it all. Basically, I think XOOPS to just stick to being a backbone application that other 3rd party applications use to exchange data and resouces, which is then outputed to the screen or stored in the DB. This would follow the KISS rule (Keep It Simple Stupid), thereby allowing XOOPS to be the very best it can be by limiting the irons that need to be in the fire.

If XOOPS developers want true CMS functionality, let them develop a 3rd party CMS module that plugs into the XOOPS framework. Make any sense?

Ok, now that I've fried my own brain, I'm going to go to class.