"Getting" a web page XML code

Thursday 10 April 2008 1:57:48 am

Using ez 3.10

Hi, I am developing a complex menu with a big structure in mind.

For a bunch of nodes (all created by one class definition) I generate a page that has XML information as it's only code within the page is something like:

<tree id="172">
<item id="177" text="Delivery"/>
<item id="178" text="Products"/>
<item id="179" text="Extraction"/>
</tree>

So nodes can be accessed by the javascript as content/view/xml/172, this will allow me to get the children of the node to build other links in the menu.

So the browser does not display any information at all in this kind of access, but if I view-source from the browser the code is right there as I need it.

I would like from a javascript that builds the menu to get "the code generated" in that page, but accessing a URL like www.mysite.com/index.php/content/view/xml/172 will not get the information from the page as this URL is understandable from ez but not from the javascript (I am assuming that if it should have at the end view/xml/code.html maybe it could understand it as it has a "name")

Any Ideas, maybe a different approach to this issue on how to access (get) the code that "makes" the URL page accessed as /content/view/xml/172?

thanks

Diseño Web Cuba
Web Design Cuba
www.elfosdesign.com

Sunday 04 May 2008 11:19:12 pm

Do you wonder how you reach such a page with javascript?
Or do you want to know how to create such a xml page in eZ Publihs?

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Monday 05 May 2008 2:23:30 pm

<i>I would like from a javascript that builds the menu to get "the code generated" in that page, but accessing a URL like www.mysite.com/index.php/content/view/xml/172 will not get the information from the page as this URL is understandable from ez but not from the javascript (I am assuming that if it should have at the end view/xml/code.html maybe it could understand it as it has a "name")</i>

I think you might be misunderstanding here.

I suppose you are using some ready made XmlHttpRequest js lib for the javascript to "get the xml content", but even if you do the xhr requests by hand, there is nothing in the world preventing the js calls to access an url like .../content/view/xml/172.

What might have an impact otoh is the "content-type" http header that is sent back to the client along with every web page by eZ Publish. Since it is set to text/html, javascript might have a hard time parsing it as valid xml.

To fix this you can either:

- use the layout/set view, which provides a way to set up a proper content-type in layout.ini

- build json templates instead of xml ones. Then javascript "might" be able to treat the received data as a javascript "string" regardless of content-type and convert it to usable js structures by making a single "eval" call. Way faster than the xml version

- make use of custom http headers via site.ini:
[HTTPHeaderSettings]
CustomHeader=enabled
HeaderList[]=Content-Type
Content-Type[/my/xml/content]=text/xml
(nothe that this applies the http header to a path, regardless of view mode)

hope it helps
Gaetano

Principal Consultant International Business
Member of the Community Project Board

Wednesday 07 May 2008 6:17:18 am

Sorry, I have a hard time understanding your explanation, even though it is detailed - must be the translation.

I assume the following about your setup:

- the treeview that has to be built via javascript is still part of the same, single eZ Publish site.
- the javascript that builds the treeview is also hosted on the same ezpublish server, and is in fact used on a page served by eZ Publish

About the 2 methods you describe for having the existing js lib generate the treeview, I assume you mean:
1 - the html+js page that renders the treeview makes xhr calls to another url to fetch the xml that describes the node structure
2 - the html+js page that renders the treeview finds the xml string that describes the node structure inside itself, as a javascript var

option 1 is more flexible, 2 is faster

In any case, I do not think there is any need for an eZ Soap client here: ez soap client is a server-side component, completely unlike javascript. If you use it, you will have an eZ page making an http request to another eZ page, which is a complete waste of resources.

The way I would implement the 2 options above are:

1 - as noted in the previous response: the js code in the first page makes an xhr request to a different eZPublish page. The second requested page is full xml. The js code parses the retrieved xml and injects data in the treeview.

2 - have the xml "printed" inside the page that renders the treeview: this is even simpler, as eZ, as you said, knows how to render the treemenu node in xml. Just add to your template of the first page code like this

<script type="text/javascript">
myJsString = '{node_view_gui content_node=172 view='xml'}';
windows.onload = myLib.rendertreefromxml(myJsString);
</script>
For more docs on node_view_gui see http://ez.no/doc/ez_publish/technical_manual/4_0/reference/template_functions/visualization/node_view_gui

Final comment: "The JS is already developed and I cannot build JSON templates. Your explanation about the custom http request could be a guide, but if defined, is the JS going to "get" the XML code of the page. I mean ez will certainly get that code, but is JS going to do the same? If you could give us more information so we can carry on it will be appreciated indeed"
- ez does not "get" any xml code of pages. the browser gets the xml code, ez gets the browser request and sends back the xml
- as I said above, js is going to get exactly the same that your browser gets (if it makes the same request). It then will or will not be able to make use of what it has gotten.

Principal Consultant International Business
Member of the Community Project Board