Any chance we can get this up and running again ?

And this time, with better 3PD advocacy than what was at Miro's world of fun ?  ::)

It had been a few months since I visited our private forum  ::)

Need to talk access...... among other things

This time is actually perfect to start laying out standards and guidelines...

did any standards and guidelines actually get released?

Adz wrote:did any standards and guidelines actually get released?

No, enthusiasm for this was quickly lost when we bumped our heads against closed doors (minds) from the PTB (Miro...), and we went nowhere fast.

As I said, this is the right time to get started again on this, a perfect opportunity, in fact.

Wholeheartedly agreed

Remember, we need an equal, representative voice for all.

How's that for a standard ? 

Another thing.. quoted from a PM sent to me by Franck from 55 Thinking / YTW before he went on holidays:

Along to this new mambo structural change, I think that we could team-up & form a group that could start lobbying this new Foundation and/or official mambo bodies. Eyezberg, vavroom, you and 1 or 2 more people could try to open an independent expert space where to try to make the things evolves on a direction that we think is right for us & the community. The exact mission would have to be defined, but i think the maturity of mambo requires it. I don't feel like to be treated as 1 certificated Mambo provider alone in my so far away Spain...

Now does that sound a good vision and definition of what 3PD standards is meant to be about - not only providing standards for 3PDs, but a relevant independent expert group providing standards to everyone else (core, dev, translation, etc..) ?

Lawrence, yes, that sounds like a good definition to me

I have always thought that the 3PD Standards and Guideline team should be there as a support to the core development team as well.

For instance, the thought I'm currently playing with is that of page hierarchy.  In other words, the proper use of h1, h2, h3, etc.  Since I think the Core Dev is aiming to implement that in a future release of the CMS (5.x?), it is important that we determine some form of standard/best practice in terms of uniformity.  What elements get to use h1, what elements get to use h2, etc.  Once *that* standard has been thought of and evaluated, we can outline it for component/module developers, so they can start leaving tables behind. 

For something like that, I think it's important for a group of "experts" to get together and give solid advice to the core devs.  They have enough to worry about with getting the code to work, if they have a good outline of what their code should produce and why, it can only make their job easier (and no, I'm not trying to impose a particular view on the devs, just thinking that this may not be their field of expertise, whereas we have several people here who do work with this a fair bit that would be able to assist.)

My two cents...

[me=vavroom]is off to find stingrey and PM him about forming this team up again officially [/me]

My thoughts about page hierarchy are already public.

absalom wrote:My thoughts about page hierarchy are already public.

Where? What? 

Here ya go.

http://www.absalom.biz/Services/News/Ma ... Ideas.html

BRILLIANT!!!

Simply brilliant.

I couldn't have written it better (and I don't mean to sound arrogant here)... 

I absolutely agree 110% on the page hierarchy notes. 

There are lots of things that need to be sorted out with respect to standards and guidelines.  I hope we get some information put together soon.  I'd be glad to help where I can. 

Louis

I'm on board as well! I think it's important Mambo stands up and be counted in the standards world, because for a lot of people, only some of the more popular blogging tools like wordpress and textpattern (which incidentally I love!) incorporate many standards features.

Like Vavroom already pointed out, and which absalom wrote brilliantly about, we need to put more effort into the semantics of mambo's default document structure (I know there have been steps in this direction), and I would love to see some more accessibility features such as title attribute and accesskey integrated into the core release (Absalom I know you've sorta already accomplished this in your project orange).

I'd also like to a decent site-map component that generates the links via lists in the core.. I think it's important for most sites to have this feature, and if it could be included as a simply link then happy days!

On another related note, whilst talking about semantic headings, I believe mambo has a rediculous amount of CSS classes going on. Many CSS designs can be accused of what is known as 'divitis', and going overboard on the classes. The idea is to reduce code bloat, and many people making the transitionfrom tables to divs simply whack in loads of nested divs, as opposed neseted tables.

A prime example is the menu system, which spits out a class of mainlevel for the menu items. This is entirely unecessary, as is the sublevel class, and only adds to page-weight. Careful use of CSS selectors make these classes obsolete. Just some food for thought...

I love the idea of a webstandards based CMS, but let's not forget that we designers and developers use Firefox, while the audience still uses IE.
But, with a good structure we can of course set things straight in the CSS, like we do allready.

And a second but: as far as I know, this is allready in the planning for version 5.0, so there will be thoughts about this in the dev team too. Don't forget they have a designer in their mids.

For sure, but it doesn't take too much to get web standards to work in IE, and many of the templates for mambo are quite simple. We're not talking about hugely advanced CSS here (which wouldn't be appropriate anyway for the average mambo user)

I agree. But what we are looking for in 5.0 is a scheme in which every design is possible. Wat would be the ideal is a structure with which on ecan build a simple straight design/template for the average user and make it possible for professional designers to get loose.  Csszengarden could be an inspiration for this.

This is turning into an interesting discussion, perhaps it ought to be split into its own thread, as it is diverging from the original topic of reforming the 3PD G&S team

We have to be careful of not falling into the trap of having so many divs and spans that it's a real mess.  blue-kiwi, I hear you about extra classes, but in fact, they aren't necessarily too many.  I like the idea of being able to have control over every single element, allowing work along the lines of the CSS Zen Garden, as Tom mentions.

While I find it important to deliver content that is good looking for IE users, I refuse to aim for anything less than compliance to standards.  It may mean for designers to use ugly hacks, but if we keep giving out code to please IE, then IE will never comply to standards (not that there's a huge risk of that happening anyway...)

Having the option to turn a div on or off, and to name it would be ideal.  This would allow designers to use as many divs and spans as required, while prodiving pared down code to those who dont' need it...

But that's quite separate from the issue of necessiting proper hierarchy/semantics for pages...

My 2 cents.

p.s.  Tom, why is your sig saying tastymouse.com but pointing to phpbb's site?

Hi Nic, i agree with all you say.
And for the false link in my signature: that was a very stupid mistake of me, thanks for the warning.

(edit: by the way, i'll translate my site into english asap)

TomT wrote:I agree. But what we are looking for in 5.0 is a scheme in which every design is possible. Wat would be the ideal is a structure with which on ecan build a simple straight design/template for the average user and make it possible for professional designers to get loose.  Csszengarden could be an inspiration for this.

This is in part why I wrote what I did.

I analysed the code for the Zen Garden in 2004, took it to pieces, and understood why Dave Shea constructed it the way he did, and then tried to relate it to how we construct each area of the CMS.

and

should become part of the templating structure standards.

is already being used inside the CMS, and just needs to be applied both across the core as a standard, and in educating 3PDs in how they construct semantic componentry and modules.

through to can be done on the actual content itself using TinyMCE or an equivalent tool.

I only picked up the Zen of CSS Design about a month ago, and it confirmed what I said about designing semantically, as Dave's explanation was pretty much on par with my understanding of it.

i'm back as well.

i'm going to instruct a few of my collegues about how i would like to see mambo development within the compagny i work for.

Can I pitch in here and point out that the single most useful standard for 3PD would be a standard content object which includes all the basic data elements required to hook an item of content in the platform/backend interface.

With that in place - which I know is a task for the next full version release - writing components becomes much easier as when you design your data structures your start with the standard content object and extend to create each different type content item.

All content items then share the same basic structure which enables the platform to provide standard APIs for both front end display and backend administration of content, speeding up component development as a whole.

there is a mosContent object (in includes/mambo.php i think)


It appears this is very much what you are looking for


Louis

webImagery wrote:there is a mosContent object (in includes/mambo.php i think)


It appears this is very much what you are looking for


Louis

Not quite, Louis.

For one thing, a standard content object should not include content fields like title_alias, Introtext and fulltext - all it should provide is the control data for a content item, allowing the 3PD to define the actual content data fields by extension of the object.

Second the existing class current provides no functions/methods for manipulating/returning control data - as I mentioned this is really something for the next full version and to capitalise on the new object handling in PHP5 - the ideal situation would be for all the functionality required to manipulate the control data to be built into the object, leaving the 3PD only to have to worry about coding for the content itself.

The other thng missing at the moment, of course, are the 'hooks' necessary to implement a full group based ACL.

What I'm really saying is that the existing content object is, shall we say, a work in progress which needs to be completed at future date.

ok, so you are looking for something like an abstract data object?

I'm not quite following i don't think.  By content i understood you to mean a content item from the database.  That being the case, the fields are defined in the DDL and correlate directly to the mosContent data object.

Are you looking for something more like hte mosdbtable class which is an abstract data object that mosContent extends?


I'm all about creating data objects and having API hooks to whatever, i'm just not sure that i'm following what it is you are looking for... and interested

Louis

webImagery wrote:ok, so you are looking for something like an abstract data object?

I'm not quite following i don't think.  By content i understood you to mean a content item from the database.  That being the case, the fields are defined in the DDL and correlate directly to the mosContent data object.

Are you looking for something more like hte mosdbtable class which is an abstract data object that mosContent extends?


I'm all about creating data objects and having API hooks to whatever, i'm just not sure that i'm following what it is you are looking for... and interested

Louis

mosDBtable covers the main bases for this but needs extending to provide a complete control object, including the full ACL, with the full set of methods and functions - what I have in mind is that if the control object is fully specified and defined then -

a) future updates should never break components as the control data and underlying table structures never change.

b) coding the backend of components becomes largely a matter of calling standard API routines unless dealing with actual content itself - so controlling the content becomes a full standardised and easily implemented process - hence (hopefully) a move away from throd party components with non-standard back end interfaces as the core system provides all the interface you need to manage records, leaving you only with the job of coding the content handling routines - where we, hopefully, then arrive at is a situation where all third party components integrate seemlessly with the backend system, give or take the occasional very complex component, like an integrated forum.

As I said, we're talking a fundamental shift in the design nethodology here, which is why this is something for next full iteration - version 5 - as it requires a complete ground-up rebuld of the system using what amounts to the same design methodlogy as bulding a compiler. Instead of building a CMS, you create a web application framework and then build the CMS on top of it, with the application framework also providing the basis for the next generation of third party components.

@unity: I'm very impressed with your expertise on this matter, and I'm sure that whoever's leading the various 3PD 'units' will be glad to have you onboard!

In terms of the framework it sounds like your describing something like rails, written in Ruby, or django, written in Python (and no I don't have any programming skills, just spend far too much time reading web blogs in my bloglines account!). I'll leave programming to people far clever than I, and just make it all look pretty!

ahh... ok, makes sense now...

What i was trying ot envision was something more immediate.  I agree that the system as we move to 5.0 needs to be treated more like an app framework than a CMS.  Truth is, its more of an app framework than what most people think of as a CMS currently in my view.  Its somewhat like a hybrid. 

I like where this thread is going.


Louis