Joomla! Discussion Forums

Thanks a lot, It's very interesting Sharon Gaughan and above all very informative. I know not to be at your level (I have to learn more and more) but if these clear notes are obvious by experts why we don't read a clear roadmap ?!

I quote what IMHO is important not to forget, I hope is just a possibility for avoiding any delay and lacks of time and for a bigger dev community:



here is another problem of J! - it's not a direct ajax concern as we are at the "source", this trouble is at the top of all other problems... I ask you whether I right... I hope to be wrong 

This thread deals with an important problem, one with even larger implications. I hope it continues, in a respectful manner, until we achieve some sense of mutual understanding and comfort.



Granted, but what about timeliness? Ajax has gone commercial at major sites on the web. I concede that some of the implementations are deficient, but the situation will settle down in time. A lot of industrial-strength middleware already features fully asynchronous communications. It won't be long before it reaches the Open Source and the web desktop in a more mature form. If Joomla! doesn't do it soon, someone else will.



As I see it, Joomla! (and other CMSs with an orthodox past), runs behind the times and tries to catch up. Louis, you made some intereting remarks about researching a fullscale javascript framework and a Joomla! specific ajax library. I mentioned earlier in this thread an approach to do so. Stating what I said in an expanded format:

(1) Immediately include common libraries, external to the core, to support non-native capabilities, such as Ajax, for existing and near-term components. Help resolve conflicts among those components. This would impose no delays on the delivery of Joomla! 1.5 or the point releases thereafter.

(2) Plan for true asynchrony by refactoring asnd upgrading the Joomla! core to handle "OS-application server-application-web interface"  communications. In the real world, that might be "Linux-Apache-Joomla!-Firefox" or "OS-IIS-Joomla!-Explorer" or whatever. It makes no difference what is communicating to what, provided all parties adhere to standards.

(3) Architect the core upgrade to clearly separate "native" enabling capabilities from external libraries that are technology-specific.

(4) Insert the key long-term steps into the Roadmap as a downstream "must-have" priority.

Preparing a framework for Joomla! is a good approach as it abstracts from native capability and specific implementations. It has the potential to allow for multiple instantiations of major applications (think Joomla! multi-site), accommodate co-resident apps (like an external data cleansing program called by the CMS backend on the fly), and any number of interesting things. If we can resolve the asynch communication issue, it will be possible to refresh multiple sites with common content in near real time.

From the end-user's point of view, Joomla! is more than the core CMS. It is the stable release plus the templates, components, modules, and plugins in toto. The user apprehends the resulting system as a whole. 3PDs do not just extend Joomla!, they are an actual part of Joomla! development. The end-user cares not a whit about organizational niceties, only the results delivered to the desktop.

These considerations are non-trivial and naturally lead to some comments on process.

In my opinion, the overall software architecture, requirements management, and roadmap (prioritization) appear to be the products of a nearly closed process. I say "appears" because that is the way it looks from the outside looking in. Transparency in Open Source development is more than being told what will happen. It includes visibility of the underlying rationale, an opportunity to help formulate alternatives, and participation in the final decisions.

I understand there are working groups, but they appear generic and phase driven, appropriate for release management, while not touching on root assumptions.

Respectfully submitted,
Sharon

You need to ask youselfs the following question:
Do you want a cms full of half integrated libs etc or do you want a cms that is stable and so flexible that if you want to use AJAX for example than you can with little work.

My choise is this, get 1.5 stable soon and let 3pd get used to the new super powerfull framework first. Using the framework to the fullest is something else than coding for 1.0.x

The thing with AJAX is that you need to build things the "normal" way first and spice it up with AJAX after that or your app will be useless.

I have great faith in the fact that Joomla will have an integrated version which flows with the new framework way of thinking in future versions.

Oh and uh, AJAX is not the holy grail. [ A stable 1.5 is btw ;-) ]

Arno

Welcome back stranger.

I agree that the priority must be to get a stable 1.5 out asap.

I think the issues here are really two things

1.) the file location of the xajax library

2.) the implementation of something that allows more than one extension to access the library.

As far as I can see its as simple as that and not really a debate on whether the entire cms should be ajax-ified

Hey Brian, you married yet or what? ;-)

1) There is no xajax lib in 1.5 only a quick implementation in the installation dir which should be trashed after install.
2) There is no choise made on which ajax lib would fit joomla and Louis pointed out some ways how you as a developer could install any lib yourself. Let me ad a very new top secret technique to that, ssst don't tell anyone, it's called ftp ;-)

Arno

Thankls Brian for summing up exactly my reasons for starting this thread.

At the moment the inclusion of xAJAX in any admin or frontend component of Joomla 1.5 would mean that other components/plugins/solutions would NOT be able to provide xAJAX.  Commercial of Free.  The simple matter is only one xAJAX can be loaded at a time.

As I hear it from 2 core developers now, com_menus will not have ANY xajax in them and the xAJAX distribution in /installlation/ will be removed when the user is forced to rename/remove that folder post-installation.

The solution proposed allows multiple components/plugins to harness the power of xAJAX simultaniously.  By inserting xAJAX in com_menus (or indeed anywhere in the core code) the core developers would have broken any chance of a global 3rd party solution to the problem.

Therefore I think we will be ok.  We being developers that write complex components (for free and for commercial gain).

As for debate,  I only ever hear of the one AJAX implementation - xAJAX - no one even rates any of the other AJAX Libs available - all discussion on these forums is (almost exclusivly) xAJAX.

I personally do not see why the xAJAX library should be located in the installer folder when it could be in the libraires folder for all to make use of AFTER installation and the installer could also use it from there - however I understand that Joomla doesnt use xAJAX anywhere apart from the installer so I guess that is a reason.

Sharon, I love your post. You said in so much better words exactly what my impression has been for a very long time (in internet years).
One simple question I think sums up most of it: who is Joomla! for?

Reading Franck's (55thinking) recent posts about using J! with large companies, Phils request for bringing xAJAX into Core, absaloms drive for accessibility and compliance, all the many posts demanding! ACL, and then to be told that all this will be taken care of / considered only after 1.5 is out, after all this wait, seems hard to digest.

People using Joomla! now I think have found ways to work around most of the shortcomings of the current code to get what they need for their site(s), like JACL+, a8e and Phils plugin.

So we have 1.5 still not in beta which will, once stable, "only" be a rewritten framework without any of theses features everyone(?) wants and needs, which the dev's are trying to get ready; and we have 3rd party extensions fullfilling needs currently not met by the CMS, but with compat' problems amongst them.

Now (I'm not going to re-read all of the posts, sorry if I get some things wrong), wouldn't it be much better for the whole community if all of the dev's using ajax or planning to got together, agreed on using this plugin for the 1.0 codebase as it seems to work fine, maybe also use the occasion to talk about other compat' problems (see one of my posts in here), and started some better collaboration completely independent from Joomla! core!!?

Many of the points you raise Sharon I have tried in a bit more rude words (apologies) to get answered a few times -I now think it is best, even though this is urgent, and answers are important, to wait for 1.5
Why? because 1.5 will be the first real Joomla! version. And because apparently it is so extensible that most problems can be solved in a much easier way. And because the team can stay focused on this. Because once it's out, everyone will be proud of it, happy with what it brings, eager to extend it's core, and the dev team will get a break and be able to concentrate on non-release related tasks, such as community communication and the some real hard thinking about "where do we want to go from here, who is this all for" etc can be done with a mind much more at rest.

I would also like more insight into the "root assumptions" and have been waiting a few years for that, maybe it'll be done some day? I am very sure this is very important to know about for quite some people here for their businesses, but most of you good folks have been around longer or as long as me; we're still here, so can we wait for 1.5?

Jicks and brians posts since I started this post seem to indicate we can.
Phils plugin is for for 1.0, so all dev's: use it it's free. que sera sera in 1.5
File location in installer has been explained by Louis?! And again by Jick, and now Phil..

Afterthought: maybe someone is working on an updated roadmap with things to expect hopefully for 1.6 ? (ie, before Joomla! 2.0)

This has started !

Azurl and I worked on the first draft version of the plugin which is currently known to power the following components (And I guess others we dont know about!)

• Tag/Tags
• mosKnoeledgebase
• jomComment
• jReviews

There is a project website http://www.xajax-joomla.com
A solution documented: http://www.xajax-joomla.com/index.php?o ... &Itemid=26
A Support Forum: http://forum.phil-taylor.com/index.php/board,13.0.html
A file download for Joomla 1.0.x: http://forge.joomla.org/sf/frs/do/listR ... jax4joomla
A Bug tracker: http://forge.joomla.org/sf/tracker/do/l ... acker.bugs
An SVN for Joomla 1.0.x and Joomla 1.5 plugins: http://scm.joomla.org/svn/repos/xajax4joomla

Yes, this is one point.
What about the same thing for all CMTs that hack core files? (as an example..)

The facts as I read them:

Joomla desparately needs:
- Enhanced menu system
- ACL (usergroup permissions and workflow management)
- AJAX library

We've aready been told that Joomla 1.5 will not contain any of these.


There are "hacks" and plugins which give us these functionalities:
- Extended Menu
- JACL+
- XAJAX by PhilTaylor

Point: Joomla developers (via SoC projects) are coming up with solutions which will be even more robust than these existing "hacks" for the core of 2.0 and have chosen NOT to fold these 3 hacks into the product because it will become a straightjacket later on.

Counterpoint: Joomla will be asking component and module developers to partially rewrite their add-ons for 2.0 because of the new nodular menu system, JACL, and other reasons, so who cares if they might also have to adapt their AJAX implentations to use a different library if Joomla devs switch libraries from 1.5 to 2.0?

Personally, I'd like to see JACL+ and XAJAX or something similar folded into the core to greatly minimize code hacks, but Joomla devs want to look at all the solutions and make sure they're using the most powerful, forward-looking solution available to solve each problem so devs don't have to rewrite twice.

Well thats a problem.

All it takes is a bit of understanding about custom development on the core team's side and then for them to provide MORE hooks, or mambot triggers and all that would be resolved.

For example, to add a new Tab to the content editing screen we have to hack the core files - it should be easy to add a tab using a plugin/mambot trigger (In fact we do it in a custom Joomla version we use elsewhere)

Remember - the whole reason we have mambots/plugins today is because I needed to put a comment box at the end of content items for ComboMAX - that was the reason mambots were invented in Mambo.

Mambots were created to support commercial components! Ironic!

Joomla 1.5 should give us better ability to extend joomla - but conflicts are still going to arise.

False promises.

I was one of the original developers that started saying ACL will come in Mambo 4.6, that was 3 years ago.  I'm sorry for starting a trend.

It seems anything that is major is quoted to "be coming in a later version" however the features of Joomla 1.0.12 are exactly the same as Mambo 4.5.0 - and not much has changed in Joomla 1.5 (Relating to core features such as SEF handling, Node based schema, Database abstraction, ACL, CSS, Standards compliant etc...)

It seems all the big issues keep getting pushed back and back. hehe

Google Summer of Code projects have NEVER been integrated into the Core of Mambo or Joomla. (I know this years will be here in Joomla 2.0 - but we have not even got a Joomla 1.5 yet!)

We are being promised by Johan and Team that Joomla 1.5 will make it easier to acheive all these major innovations mentioned above- so lets just wait and see if this really is the case.

We are all getting distratced here lets get back to the two original issues



Everything else is a smokescreen right now and is leading to debate that it is off topic for this thread.

If you want to debate what is or isnt in 1,5 etc then there are many threads you can do that in;)

My thoughts...
First, on the xajax issue...  I am satisfied with Louis' response on this issue.  I don't see a reason to demand that this functionality go into the core...  it makes sense to me to have a plugin type installation.  This plugin could perhaps even install the xajax library (or a derivate of it based on the previous initiative to make xajax code that plays together with other extensions i.e. the standard) in the libraries folder.

What I see Louis' argument being against putting this in the standard install is that it seems like the number of third party libraries in this folder are to be minimized - there were none added in 1.5 except two, which were not so much additions but replacement for older libraries.  Though off hand I'm not sure phputf8 was there, but again this was specifically for UTF-8.

There is hesitancy to but a less than optimal solution into the core - that is the issue.  It will take some time to get a full scale ajax library into Joomla!, so rather than putting something that will be obsoleted into the core, it has been decided to leave it out.

I think the issue of timeliness is a good one.  Therefore I would like to propose that there should be a non-base install, recommended solution for ajax (specifically an xajax implementation).  This would be under the category of 'this isn't something that we are committing to be in the core for the next few major releases, but it is a working solution, and there is a solid team to support it'.  This would be an iterim solution, but would be usable by extensions long term.  When the fullscale solution arrives, developers can use the old (non-base install) solution, or can use the new fullscale one.

I ask the question: what do we lose from this approach?

Ian

P.S.  I think Joe is right in raising issues of communication and community, etc...  These are things that we need to talk about - but let's focus on helping the development team get 1.5 out and the rest of the community building support around it first.

The lack of ACL is something that will keep Joomla as a hobby project (sorry about the insult) and never move it to the professional level that it deserves. Personally I would wait 2 years for the release of 1.5, if it included a proper ACL



YES and thank god for those hacks. People are demanding Ajax right now. I think that 3 party developers will be using Phil’s bot to give ajax features to the users now. If another ajax will be implemented in version 2.0 we will still have a mixture of hacks and core that causes more trouble that good.

So if this is the situation, that many 3rd party components will include this, because of the demand in the "market", why not make a statement that it will be supported, and get working on the other issues, instead of reinventing the wheel all the time.

However all our thoughs aren't for this next 1.5 version. It's important not to run for a "bad" solution but I have to consider that at the moment there is No solution at all! Besides I remember in the old mambo years what posted:



I think the story has changed, I think that the first starting point is to have our real new FIRST JOOMLA CMS that it'll be the 1.5 version. From this first real step we have to roadmap (timelineness ?) everything. Our fear, that is the fear of "old" member of historic mambo is not to see the same storic waiting. But all has changed, and ajax (or as per Sharon ideas, too) is a big and extremely urgent issue. I see that (sorry for this declaration but it is only for "shaking" this discussion in a propositive way) Drupal about ajax in its news appears to be a step beyond, and us

But we apparently DO have a solution - Phil has developed a plugin that will solve this problem.  Why do we need to look farther in the interim?  1.5 was designed so that these types of things could be done in a way that does not involve core hacking.

I think we need to make a distinction between hack and extensions...
ACL is a hack because it changes the core files.  Everytime a new version is released, this needs to be redone.  One of the SEO solutions I think is a hack...

Phil's bot is not (I don't think - based only on what I have read in this topic) what I would consider a hack.  It does not overwrite any core files.  It installs new files and uses the hooks provided in the Joomla! core to provide new functionality.  To me this is something totally different.

A plugin is maintainable, a hack is much more difficult to maintain.

Even if xajax was to be included in the base install, some would still probably use other libraries.

Part of the issue that IMO started the thread has been solved - the issue was that Joomla! base code that implemented xajax would prevent 3pds from using xajax.  It has been determined that this is not the case.  We can use Phil's solution as an interim - not as a hack but as an alternative.  It has been stated that there will be AJAX support, but not yet because this takes time.  We have to accept that.  I don't see how this creates a problem.

Ian

ian: I'm not trying to raise issues, I completely agree: let's focus on 1.5

The thread, according to provided explanations, has become useless by now:
installation folder is (supposed to be) removed and not part of the CMS, in the menu folder there won't be any more xajax files, so as long as all 3rd party devs agree to use Phils solution, everything is cool, right?!

If something is included in the core, like a specific AJAX library, then that is a de facto declaration that THAT is the AJAX library that Joomla wants all component and module developers to use. We've already heard from a Dev that they have NOT decided that xAjax is the library they want to be used now and forever and are still researching. Just like in the JACL thread, I heard from the SoC team member that JACL+ is interesting but not the direction that JACL for Joomla 2.0 will be going.

As others have already summed up, if PhilTaylor's xAjax is easy to install and all J! devs that need AJAX choose to standardize on it, then there's really no problem until Joomla 2.0 when the "official" AJAX library gets folded into the core.

There are a couple of loose ends.

First, I think there is a feeling among many that the current, pre 2.0, Joomla! distribution include Xajax as an interim solution only until the long-term solution arrives. That way, 3PDs extensions have ready access to the resource and minimize problems for the end user.

Second, the contributors to this thread made a lot of interesting comments that could have a real impact on Joomla! down the line. It would be a shame if those insights were lost in the archive someplace.

Agreed, Joe...

And I wasn't saying you were...  I appreciated how you decided to hold off...  the reason for my comment was that I had actually written about a page of stuff about thoughts regarding community, but after reading your comment decided to hold my tongue...  I have seen the work of the development team and am impressed - it has been a wait, but I can see why...  if you have ever done construction work in a place that was constructed completely wrong, it can be an incredibly frustrating thing.  It is my hope that 1.5 will get the code foundation in order - a LOT needed to be redone, this has taken much more time that I think anybody ever anticipated.  With a solid foundation in place, it is my hope that future releases will be much easier to pull off (and I think this is the intention).  Even developers don't link to play in a trash heap 

I think you have good things to say, Joe.  You seem to think you have hurt people in the past by the way you have brought these things forward.  Let's all work on learning to speak with grace in order to communicate our thoughts.  You have done well, Joe.  You have my respect.

Ian

I think it is a good (temporary) decision 

One more thing:


http://www.openajax.org/openajax-hub.html

OpenAjax: Adobe, BEA, Borland, Google, IBM, Ilog, Mozilla, Novell, Opera, Oracle, Red Had, SAP, Software AG, Sun, Tibco, Zend...

I really wonder if you've taken a proper look at the end-evaluations, the mid-term evaluations and even the project descriptions. This may sound harsch, but if you've taken a look you should see that at least 1 project is fully implemented in Joomla! 1.5. This project is J!Explorer, and contains web services. J!Explorer is a modular Java framework that allows end-users to communicate with a Joomla-website in a complete native way. As a end-user, I'd be quite happy with this.

Other projects, such as ACL, WebDAV, AJAX and cross-DB support weren't finished in time. Why? Because those projects are huge to develop. Joomla is scheduled to be released around this time; the SOC-projects started 3 months ago. What do you expect? Develop and engineer all this in 3 months, PLUS integrate it in a distribution in that short amount of time? Another issue is to guarantee the quality of work. All those items have be kept in mind, especially if the Joomla! project wants to release the framework on its own.

I can understand your frustration, but please consideer to take a look on the other side. Aren't we all on the same side?

Laurens

I'd like to see a comment by Sharon 



I think you're right: hard work and few time But also:  - Students should be enforced to treat SocC as full-time job! (and they get paid for it!)

[one of the last sentences at page 17 - Joomla! Summer of Code 2006 End term Evaluation v.10]

I presume is a general statement, not for J!, perhaps the same sentence I can see about Drupal... but I dislike to see that written. Stop! This is only for a complete truth.

Blush 

The Alliance was founded to deal with interoperability issues, particularly those that occur in Business-2-Business (B2B) situations.

Middleware applications on a website may be fully asynch and mated with a presentation that is not. Another site may be in the same circumstance, but each sites could have a different combination of apps. They then have to communicate with each other. A shopper might buy something from an online vendor, with the results passed to another site invisible to the customer who believes they are still on the original (ordering) site. Each of the websites involved may handle bi-directional asynch communications in a different manner, using different libraries. A fine mess.

The messiest of all is when a website page is assembled on the fly by integrating a group of mini-apps (think components, modules, and/or mambots) from different vendors using different libraries. All kinds of contention can occur.

However, the OpenAjax Hub project is just the first step in resolving th problem. Right now, it focuses on finding ways to bridge differences among the various libraries used by different organizations. They will do this near-time by producing a lightweight ECMAScript library (OpenAjax Hub) to enforce consistency and avoid nomenclature and namespace collisions.

Private discussions have been underway for some time on the downstream evolution of the (eventually) standard foundation library. "Foundation" because it will deal only with what is under the hood and permit value-added and market-worthy extensions from individual vendors.

A theme common with the Joomla! project is to encourage a one-to-many relationship between the Framework core and extensions that exploit the core in tandem with value-added features. Under this approach, 3PD developers should not have to install the same standardized library again and again. It would be installed once and stay there for all to use. Only specialized library additions would be installed. Later on, with further development0, a mature OpenAjaxHub can be installed.

This is one of the reasons why why I support the long term (2.0?) goal of a tight, clean and up-to-date upgrade of the Joomla! core. However, I also support placing xAJAX in the standard distribution (not the core) as an interim measure pending further development over the next year. If xAJAX goes to the next version, then it is updated once (in the distro) and 3PDs simply hook on.

During the wait for 2.0, we can explore OpenAjax and other approachs to see if there is a sensible convergence of interests.

Please note that Zend is a member of both Eclipse and OpenAjax. The Joomla! core team may be using OpenAjax in its development environment before deciding to actually use it. An interesting thought, that.

Hi all,

I have written a small blog postabout (x)AJAX in Joomla! 1.5. I hope it adresses some of your questions and concerns. On Phil's request the developer working group has also taken a look at his proposed xAJAX plugin. The feedback is summerised in the post.

Johan

I will refrain from commenting as it is clear that my involvement with communicating with the core Joomla Team has come to an end and only incites more anger and abusive mails to my mailbox from developers and community members.  It is clear to me now that my involvement with the Joomla project is not only not needed (Which I knew), but unwelcome.

@ Phil Taylor - I'm very satisfied about that blog post, it's a clear one. I don't know about your private mailbox affair but pls don't think about your involvement as a priority in the J! roadmap... we are a community with its rules and decisions... and I repeat the blog post is very clear and I hope to see a clarification by "guilties" in private form to you. bye

Yeap we need to keep cool 

Having said that I think this is a major issue.  One of the reason Joomla is so successful is because it has many extensions.
I also develop components and find myself telling my users well this is going to be possible when Joomla will implement this and that. 
Not that it is not possible without Joomla but it would take for ever to develop something nice.
I am waiting for Joomla 1.5 to develop some cool features.  The use of Ajax in my component was one of the things which is on stand by.  By reading this thread I realized even more the challenges ... due to possible conflicts.

Phil could be a little bit more gentle when bringing an issue forth and I also understand his frustrations 

Components can only be as good as Joomla is

Make a Joomla a consistent and robust framework and extensions developpers will help make Joomla the best and most used CMS on the planet. 
We need to work together on this ... isn't what Joomla is all about after all? 
Chris