Joomla! Discussion Forums

http://blog.phil-taylor.com/2006/09/20/ ... joomla-15/




Discuss


Further Reading:
The current Joomla 1.0.x xAJAX Plugin for Joomla (Known to be Used by 8 Components! after 1 month of release)
http://www.xajax-joomla.com/

Here is the proof of concept.

Install this as a Plugin in Joomla 1.5
Publish The plugin
In your component (com_example) add the two example xAJAX handler files xajax.example.php and admin.xajax.example.php (Included in this zip file)

in these two files define your own functions making sure you add them to the register array at the top of the files.

It works - its tested - is FREE (LGPL) and its being activly developed by SEVERAL developers (This is not just a Phil Taylor idea! )

DOWNLOAD NOW BELOW

What read is very interesting, I'll test it ASAP 

..I've forgotten to write about a Commercial component that I see by http://www.Mamboassistance.com called AJAX Fly (a Solution AJAX for Joomla - A solution which makes it possible to give speed to your Internet site).

It makes possible to quickly charge the contents of a page without having to charge the page entirely and it isn't free  you have to pay 20$ per site.

I know to be NOT an expert of Ajax technology but I hope to see more ajax in 1.5 (in Google summer code about ajax we have NO work finished!) and as a consequence I'd like to repeat what said by PhilTaylor-Prazgod:

Have you formally submitted the concept code to the team? If so, what was the response?

However it is done, there is a very real need for an elegant Ajax solution is 1.5. Until recently, we have had extensions that could not be used together because of contention among them for priority.

I do not believe that there is a formal way to submit code to the developers for review, apart from a forum thread.

I have skyped the url for this forum thread and the link to my blog to Johan and several others.

I am happy to do the work for the developers so that their time is not taken up.

Hmmn. someone far more knowlegeable than me would have to comment. Looking around, I don't see a mechaism for code submissions per se, except for reporting bugs at
http://dev.joomla.org/content/view/14/55/#reporting%20bugs

and submitting patches at
http://dev.joomla.org/content/view/14/55/#Submitting%20patches

There is a way to request a feature at
http://forge.joomla.org/sf/tracker/do/listArtifacts/projects.joomla/tracker.feature_requests?openPriority=all

and

register a project at
http://dev.joomla.org/content/view/1092/73/

and 

report on project results at
http://forum.joomla.org/index.php/board,126.0.html

Mainly, it seems to be a roadmap problem. That is, Ajax is not explicitly mentioned at
http://dev.joomla.org/content/view/23/61/

Do I have this right or wrong?

Sorry PhilTaylor-Prazgod I don't understand what's happening... We are open source, yes... the community, but if you might have a good solution for all of us All sounds strange to me, the problem is that you are Phil Taylor... no, I don't think so, perhaps It is another good reason that we don't know 

In the forum we see a lot of threads about ajax and so on, the community is aware of this tricking technology and above all its potential, full one in J!...

I'd like to see a reply for understanding why as in another occasion I wrote in the J! dev blog comment one my personal own opinion about the "timesavingefforts helping hands" from external developers that I think might be very useful if considered (in that case I mentioned the work done by the german Run Digital).

Moreover you can read about our ajax project also in Google summer of code results : results linked from the article http://www.joomla.org/content/view/1958/74/ and as you see there is a great documentation but nothing else due lack of time! So I think there is enough room for everyone to do something  is it right my idea? It's an idea to have dev only for that particular goal, too.

I hope to see a good news 

Perhaps we can take a different tack on this subject. I think we should discuss the Joomla! architecture.

Does Ajax (without regard to the specific implementation) really belong in the core? It does not strike me as a foundational technology, but derivative of other capabilities.

The name itself refers to an implementation, not a capability ( HTML + Javascript + XMLHttp = Ajax ). Not only is Ajax evolving, but it could be supplanted in the future. After all, Any one of those three terms in the equation could be replaced with something better and we would still have an Ajax-like result. Then of course, we have things like XUL, XAML and XForms coming up. How would all that fit together if a specific Ajax implementation became part of the Joomla! core?

Currently, Joomla! distinguishes between components, modules, and plugins (with some overlap). 3Pds can and do come up with components and modules that purport to "replace" parts of the Joomla! core. But, say, weblinks isn't a core component, is it? Architecturally speaking, isn't it just an end-user component that ships with the core to provide minimum capability? Weblinks, or the like, can be extended or replaced by clever 3Pds Perhaps not now, but with 1.5 and beyond).

I recognize that it isn't as simple as that, given the current overlaps between foundational code in core and what otherwise would be sample applications included in the current distribution. But aren't we striving for a tight and capable kernel that will support modules, components, and plugins that communicate through an appropriate abstraction layer to obtain services?

One can visualize any number of Ajax or Ajax-like implementations (plus future developments) that provide the capability for selective delivery of user data and the accompanying partial screen refresh. I suspect that is best handled via an appropriately abstract presentation layer.

Never has any Google Summer of Code project Ever been included in Mambo or Joomla core !



Historical Politics.

Yes it should be in the core. It is more foundational that the majority of 3rd party libraries that are in the libraries folder of Joomla 1.5



XUL, XAML and XForms will never be in Joomla Core unless the Joomla developers take a huge jump from what they are doing now.  They are all technologies (apart frm maybe xForms) that are more browser specific.



The overlap is the main issue when it comes to using xAJAX. xAJAX can only be instanated ONCE - we need a system that can grab all the methods from all the components, plugins and modules on that page and add their methods to the single xAJAX hangler in the head of the HTML document.



My point exactly !!!  Thats why a plugin for xAJAX makes sense instead of the way Joomla Core developers are just "dumping" xajax files anywhere.  If they are ging to use xAJAX then the files should reside in /libraries/ and should be available to al components, plugins and modules through an abstration layer (such as the xAJAX for Joomla Plugin proposed!)



Agreed.  By with the current system in Joomla 1.0.x we have learnt that multiple xAJAX components will fall over each other so we need some central layer that each component can register its method calls with and then a generic (abstration layer) xAJAX object that will display the required Javascript in the head of the component and process and route the incoming xAJAX calls.

This is the main point, even Drupal has the same question as Every CMS around the net. But which is the J! reply about ajax? Without a clear reply all other talks aren't necessary at this stage, well... 

Looking through the working group organization, I don't see one that covers architectural questions that span the lifecycle.
http://dev.joomla.org/content/view/13/53/

Can anyone say how such questions are debated and settled - and how the endpoint architecture is defined and documented?

Never has any Google Summer of Code project Ever been included in Mambo or Joomla core !


Here are quotes from
http://dev.joomla.org/components/com_jd ... .v.1.0.pdf









I would not hold your breath for SoC to rescue us





They are debated here in the forum - and settled when one of the core developers decides to take an interest in a certain item and integrates it into the core. Then someone else in another team tries to pick through the code and document the system.

SoC is not meaning to be integrated into 1.5, even less 1.0, it clearly says:

on the initial intro.

I agree it is a nice solution to have a plugin do all the work for any and every component, as I can just unpublish it if not needed.
But (as I reported under Tags component), there are still some problems with it: it includes the header code which calls at least 4 js files even where it's not needed, such as section or category listings (no taqs, no comments, no nothing there)..!

If all 3rd party dev's (haven't seen any post here) are happy with this bot, why not, if this can solve compatibility problems.

Unfortunately (this is slightly OT), this is not the only thing that needs 3rd party collab: same applies to all those component that change, patch or replace Core files (JACL+, tags, sef patch, mosmedia etc): which work together, which can with some changes, which are mutually exclusive etc..

Sure, AJAX is the big thing, and a working, GPLed solution would be nice. Some dev (core & 3rd party) input would improve and diversify the discussion..

All right, now I hope to see other posts... I'd dislike to see ajax forgotten in this way... or have I to pay for having the same ajax 

pls keep on touch, ajax is a good goal.

I am not as knowledgeable as Phil and many others out here in development matters but I have successfully included his xajax bot in my component. It really is a lot easier to implement xajax using it and my users can now happily install other xajax applications like Tags and Jomcomment without having problems.

From reading the potential problems that Phil pointed out in his original post, most importantly the backend issue of using xajax for menus, I think his solution is the best unless someone comes up with an alternative, but why do that if this one already works and quite well!

I haven't looked at Phil's plugin, but my thoughts on the matter...

I agree that it definitely seems helpful to provide a standardized method of doing AJAX in Joomla!.  Though I haven't experienced conflict myself (due to limited attempt), I can see the potential for problems in this area.

As to whether or not it should be in the core...  that seems to be more of a grey area for me.  If we stuffed everything useful in the core, there would be hundreds of extensions in the core install...  Mambo has actually gone the route of releasing a lite version without some core extensions...

On the other hand, there seem to be some fundamental things that should be in the core - base libraries, I guess you would say.  The question is whether xAJAX falls into this category.

I'm not sure it should.  Partly because I think that inclusion in the core does not mean something will get used.  Case in point, patTemplate.  This has been included since some point in 1.0, but there are many components not using it (actually, few that are).  This is partly perhaps due to learning curve...

If it were to be included in the core, I think it should be disabled by default, with some mechanism by the first extension to be installed that requires it activate it, and the last extension uninstalled deactivates it (this would be in the installer).

But this still may not stop others from implementing their own libraries, and messing things up.

Since this is a plugin, there is no reason it cannot be installed as a library for use by other extensions.

My concern would be the common concern that there is with AJAX - does it degrade gracefully on non-AJAX capable browsers?  Can the functionality still be used?

I think a good implementation would make it easy to create extensions that do degrade nicely.

If a plugin is capable of doing this, then the way to make it a standard is to make it accessible to the developers.  patTemplate never became a standard because issues were found with the performance.  This lead to a resistance in its adoption in core components, which led to lack of examples of its use in the core.  There is little great documentation on how to implement it properly in Joomla!.

I would think that this would quickly become a standard if it could solve the issue of backward compatibility with nonJS browsers AND be simple to implement.

Great documentation and selling it as an easy way to develop goes a long way.  Some way to say - hey - you want to develop in Joomla! with AJAX?  Here is a library built specially for Joomla! that will allow you to easily build extensions that are interactive, will degrade nicely and will play well with other extensions...

Just my thoughts, sorry if they are scattered...
Ian

Ian,
as Phil pointed out, xajax is already present in Core, and twice, and not in the expected folder (libraries)!
(isn't there yet another one in the install folder..? -yes, just checked: in "includes"!)
That is one part of the problem: it's there, 3 times, but not really usable as is because of conflicts.
Other part is, from what I remember reading in dev blogs or forum posts (sorry, forgot link, could search if need be) is that it will not stay in Core once the SoC code has created J!s own libraries?!

Thanks for coming by Alejo, todo bien señor?

From my own reading, it's my understanding that the SOC code needs to be rewritten (refactored) to meet development team objectives and goals that are apparently leaning toward reincarnating the Joomla! core as a development framework for 2.0 where the CMS is one of many packages that could be installed to extend that framework.

When selecting a framework, most developers look for extensibility with emphasis on adding their preferred libraries to the framework in an effort to customize it to meet their own needs.  xAJAX is not the only AJAX solution, although it could be the recommended solution.

Is there any reason why the installer could not have an extra installation page called something like Options or Recommended Extensions, allowing the xAJAX plugin to be included in the archive and optionally installed if the user wanted it? .

Have any of you ever made a search in google about AJAX and PHP.

There are MILLIONS of hits, but no really standard.
Now XAJAX is a free lib, and the buty about it is that it encapsulates the UGLY javascript code in pure PHP code.

Ajax is sometimes refered to as WEB 2.0, this is how important it is.

At the moment, I know about 3 components that are build for Joomla with XAJAX, and I konw that more are in the pipe.

I belive it would be a wise decision to include XAJAX in the core, it is open source (Remeber Open Source Matters?), it is easy to use and it is well documented.

What is there not to like.

It seems the Core either needs xAJAX as a library/plugin or doesn't need it at all - IF it would cause compatibility problems with 3PD's.

If this is a framework, it needs to be open to 3PD's not a hindrance (which the admin menu xAJAX inclusion might do).

So the options should be to either:
1) Devs follow their own guidelines and make xAJAX a library item for global use
or 2) Take it out completely and let us use plugins like Phil's
or 3) Leave xAJAX as it is- in a few different places- causing code bloat and 3PD incompatibilites

I like the idea of Phil's plugin being in the core with an option to turn it off. Then other people could create other plugins for different the different AJAX solutions.

I would not want the inclusion of xAJAX in the admin menu if it could disrupt any other 3PD admin-side solutions.

Chuck

Lets go back to the beginning here and not get sidetracked as to the various merits of an ajax library or of summer of code project integration.

My understanding of the issue is that only one instance of an xajax thingy can be called at any time.

Because of this a few 3pd developers have agreed on a system to resolve this. ( http://www.xajax-joomla.com/ )

Sounds good so far.

However because the current 1.5 now uses xajax and without the proposed fix (or an alternative solution - but why re-invent the wheel) NO 3pd extension can use xajax within joomla 1.5

I hope I have summarised that correctly.

So assuming my summation is correct all that needs to be done for xajax implementation in joomla 1.5 to be usable by all is for the adoption of a method as described / proposed by http://www.xajax-joomla.com/

Finaly it has been stated (i havent checked) that the included xajax libraries are located
    * \joomla1.5\installation\includes\xajax\
    * \joomla1.5\administrator\components\com_menus\xajax\

The whole point in creating a libraries folder in the first place was to hold third party libraries such as this.

There were many and varied reasons for creating the libraries folder all of them good. These included making updates of libraries easier and Seperating 3pd libraries from joomla code for copyright and licensing reasons.

I can only think it is an oversight that the recently introduced xajax libraries are in the wrong location and that when the menu wizard is completed they will be moved to their correct location in \libraries

I have to agree with Phil for all the reasons he has stated. And in any open source situation it is like swimming upstream to get something like this folded into the product.

AJAX needs to be part of the core. Unless Microsoft and Firefox simultaneously a new system that is browser compatible I can't see something new beyond AJAX. It is very useful for form validation, population of updated data, and reducing server load.

There is much to come.

True asynchrony is the capability of an object to send or receive a message at any time, in any direction, but Ajax-enabled web applications only provide the upstream direction. Ajax cannot by itself support collaborative applications that require “push” data streaming. Ajax in a web user interface cannot engage in real-time event notification. That's because a "pure" HTTP approach makes make server-initiated transmissions impossible.

However, the HTML loophole permits a response connection that is maintained for an extended period. An application can exploit the loophole to continuously stream data into the browser. Using what is essentially a hack, developers can combine AJAX and asynchronous event notification to create publish-and-subscribe applications that look very much like "smart"-terminal or "fat"-client applications in the back office.

It is this open response connection that causes the obvious conflicts when multiple Joomla! components each claim priority and step on each other. Even if the response window was more limited in nature, there would be timing and resource coordination issues. The limited asynch capability in Ajax is illusory.

It is only a matter of time before web services arrive that feature true asynchrony. For example, the emerging Apache Web Service stack addresses this problem (c.f. Axis x).

If we can imagine Joomla! moving in a direction that exploits emerging capabilities, then at least two needs come to my mind: (1) a near term accommodation of existing asynchronous communications, embodied in Ajax, and (2) a long term plan for elegant and orderly accommodation of further technological change.

So, how about this:

(1) plan for true asynchrony by refactoring the Joomla! core to handle "OS-application server-web interface"  communications. In the real world, that might be "Linux-Apache-Firefox" or "OS-IIS-Explorer" or whatever. It makes no difference what is communicating to what, provided all parties adhere to standards. This can be inserted on the Roadmap as a downstream "must-have" priority. It need not impose a delay on the delivery of Joomla! 1.5 or the point releases thereafter.

(2) immediately include common libraries, external to the core, to support non-native capabilities, such as Ajax, and resolve conflicts among components. Once the core is refactored, these libraries could provide the interface for calls to the new native capabilities.

Phil, your tone seems a bit angry and frustrated....

First off lets clear something up .... there is only ONE distribution of xajax in the core.  It is in the installation application.  I had put xajax in the menu manager directory as I was playing with many different ideas for user interface and wanted to use it as a way of testing user experience.  You will find if you do an SVN update, that the menu manager has been completely reworked... com_menumanager and com_menus which were separate components have been consolidated into one mvc with significantly less code and the user experience in my opinion is much much better.  It also allows for an enormous amount of flexibility in the way you build menu items.

You spewing criticisms of what is and is not in the trunk at any given point during this phase of development shows either a lack of understanding of the development process we are using or a desire to trash talk the core developers.  If it is the latter I'm greatly disappointed (not that you care).

The decision of putting xajax into the installation application was a conscious one made because it was the easiest short-term solution for getting ajax functionality into a place where we felt it greatly improved user experience and did not affect the package as a whole.  The simple fact is that it has been stated lots of times that an ajax framework will NOT ship with 1.5 ... it was that way when it was named 1.1 and it is just as true today as it was then.  There are a multitude of reasons for this not the least of which is that we have not done enough research on the different options out there to be 100% satisfied with one.

Things that find there way into our core libraries... or Joomla! framework ... do not find themselves there by accident.  They are not there because we think it solves a short term problem.  They are there because they were built to be extensible and forward looking or because they are needed for backwards compatability. 

We have stated SEVERAL times if you were to look (and I'm sure you probably have) that we will be researching a fullscale javascript framework and a Joomla! specific ajax library that can harness the power of the code we have written.  If you understood the JDocument package of the framework ... and/or looked at the work done on the JAJAX project for the summer of code, you might see that significant work has been done with regard to exposing methods and classes to an ajax interface within the Joomla! framework.  This work also abstracts between using XML or JSON and potentially abstract from using any given javascript library/framework.  This is the Joomla! way of doing things.  That is what we will pursue with regards to implementing framework level ajax libraries.

For the record, both Johan and I have had correspondence with the xajax devs and I do like the way xajax does things.  That should be painfully obvious considering that it is the library I chose to put something together for the installation application.  That does not mean, however, that using the xajax library is the best way for Joomla! ajax integration based on ease of use, performance, extensibility, etc.

As for your problem with being able to call the library only once... It seems that you have something that works for your commercial endeavors... Why should the core bend to your desires because it "works" for you and even several others if what we have on the roadmap is something that has already been started (SOC) and we believe it to be the best way forward?  Would you have us add the xajax library now so that you can use it then remove it later when we get our implementation done?  Or would you have us leave it there after we finish ours so that we have extra code bloat?  The simple fact is that if you want it in the libraries folder bad enough you will find a way.  install.{COMPONENT}.php is run anytime a component is installed and if you wanted you could quite easily write a method to check to see if /libraries/philtaylor/xajax/ was present... if not, install the lib... if so, perhaps do a version check on an XML metadata file or if you feel like taking a chance just move on and use the xajax libraries there.

Fact is, our system is extensible JUST SO you can do things like what you describe in your plugin pack... install something like this and add an xajax to Joomla.  Why complain about what isn't there because you use it instead of just using it?

Louis

Louis,

No one is picking a fight here but I've just read your post and am now even more confused than ever.

You state several things that appear to contradict each other - at least to my mind
"is that it has been stated lots of times that an ajax framework will NOT ship with 1.5" so what is xajax then?

It is irrelevant what has been done for an javascript/ajax library for the summer of code as both you and the summer of code mentor have stated that it is nowhere near implementing and so surely it wont be added to joomla 1.5 at this point.


Its not Phil's problem its the whole Joomla community

no it works for ALL endeavours not just commercial and that is an underhand swipe Louis and you should know better than that. (Its not as if you have never earned any money through your knowledge of joomla is it)



As i stated before Louis there were lots of very good reasons that the core team decided to put things like xajax in the libraries folder and I fail to see why xajax isn't put there. Why you cant just be honest and say "oops yes you're right it should be there" |Its OK we all mistakes sometimes and there is nothing wrong with owning up to it.

Finally

I am very disappointed Louis in the tone of your reply as it is very much an US v CORE reply and does not actually address the concerns/issues raised by various community members.

It may well be frustrating for you to have your code available at every stage for evaluation, warts and all, but that is the nature of open source software development. In fact it is a fundamental principle. and you must be open to feedback as a result of  this.


Johan has spoken many times about making the development of Joomla more open and more welcoming to developers so that the development of Joomla can be contributed to by far more people than today (and even on an ad hoc basis).

If this is an example how someone approaching the core team and saying "do you know you have a problem here and by the way here is the fix" is to be treated ..............

I didn't lock the thread... it was done by a moderator that likely felt the thread was going to cause a problem... again I repeat, it was not my decision.



Semantics brian... what is the first thing you do after you install Joomla!?  delete the installation folder... thus xajax is no longer a part of it.  I will as you suggest I am either incapable of or unwilling to state that I was wrong... an ajax library DOES ship with 1.5.. in the installation application that is NOT part of the CMS.  It is not part of the Joomla! framework, the Site application nor the Administration application.
Given that caveat, I was wrong xajax does ship with 1.5 ... but it is NOT for component development nor is it part of the Content Management System.

More clear?



If you had read my post you would have understood that it is not a problem.  I was toying with xajax in the menu manager and have removed it.  I believe that Johan even told Phil that in the discussion where Phil posted private conversations on the forum... He however, left that part out of his diatribe.  The fact is that phil implementing it the way he did is what broke 1.5... 1.5 did not break phil's plugin.



As far as I know Brian there were only two third party libraries added to 1.5 that 1.0 didn't have as legacy ... tcpdf and magpie... both of them were to replace existing libraries so that we could solve UTF-8 issues.  If I am in fact wrong and other libraries were added, then I stand corrected beforehand.  Nothing like xajax has been put in the libraries folder (being any sort of ajax or javascript framework)... and as I outlined in my previous post things CAN be put in the libraries folder by third party extensions if they require it.  Just because you fail to see why xajax isn't put there doesn't mean there isn't good reason either.  I respected you up until the point where you said I was dishonest about my reasons for stating what I did.  If i felt that I had made a mistake I would own up to it.  I am absolutely fallible... You are wrong about your assumptions, but I am not calling you dishonest over it.



Again, wrong ... my response does address the concerns/issues ... it just doesn't give you the answer you wanted.  I am not frustrated at all with people looking at my code.  In fact I am glad, and am one of the driving forces behind opening things up.  I am quite open to feedback, I just disagree... and you seem to percieve that as me not listening.  There is a difference between not listening and not agreeing.

Louis

I confirm here that the topic was locked by mistake.

Discussion is healthy and encouraged.
Please just do not be too personal and keep cool.

I never said it was you in fact I knew who it was

yes thank you


Sorry you miss my point about using the libraries folder but it doesnt matter




Yes there is a difference and the fact that the thread was locked by a forum moderator immediately after your post gave the impression it was done at your request and that you wished to prevent any further discussion. As i now understand it that was not the case and I apologise for that assumption.