MozillaWiki

Labs/Joey/clients/ajaxy/functional: Difference between revisions

< Labs‎ | Joey
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{draft}}
{{draft}}


== Design Overview ==  
== Design Overview - Joey AJAX Client ==  


* working on this now! - mgalli  
* Not working on this! - e-mail mgalli@mgalli.com


=== AJAX Layer Over Declarative XHTML UI ===  
=== Introduction ===


Aspect approach where CakePHP produces XHTML simplified data as the representation of the UI. In a way it is like elimating the HTML view aspect of it, or to model it so that it is very semantic and provided for the UI toolkit layer. The UI toolkit layer uses this view ( User Agent Interface - UAI ) and creates the actual UI ( user interface ).  
An aspect oriented design ( as a goal ) where CakePHP produces simplified XHTML data that is meaningful as an user interface. This interface shall be used by the Advanced Client - it could be described as an User Agent Interface. As we move forward, CakePHP content should be as semantic as possible, but at the same time we are to leave it as an 'old school' web interface, keeping its static links and forms as well. This approach should put us in a condition where the aspect of navigation and form interfaces is described separated from the Advanced AJAX navigation layer. This XHTML-based static structure should represent the navigational structure of the application. This should lead us to simplify maintenance in the CakePHP ( with simple and usable test pages ), automate tests with other tools that deals with traditional HTML page and forms. We may also simplify the usage other advanced ajax toolkit solutions.


Then have the client side AJAX toolkit to model the declarative markup to create the end-user visual interface.
=== Wishlist Architectural Aspects ===
* _Accessibility for Navigation_ - Back and Forward buttons working via iframe history. Use it possibly for the main flows. We need to check if the mixture of Back/Forward working and not working conditions is a good or bad thing for the end-user. Since it  is a AJAX UI, we may have some high very specific operations that are not to be registered in this iframe history;
* _Accessibility for Legal_ - Keep partial compatibility with Robots indexing capability and keep the basic legal documents and overview linked from the main client document ( privacy, terms of use ) - we dont want people to need a full ajax client in order to read the terms. Check Dojo links so that the app has a compabible linking mechanism;
* _Localization_ - Strings binding ( probably kicked with the initial document ) and additional flow-based sentences to be loaded in JSON or other XML binding approach;
* _Accessibility for Usage_ - Check the story;
* _Performance_ - build aspect. Check the Dojo build approach, and how to package partial Dojo components;
* _Performance_ - Dojo ShrinkSafe;


=== Dojo Considerations in the scope of Joey UI Flows ===
=== Development Framework Considerations ===


==== ContentPane ====
* To keep a simplified old school XHTML interface so that the Web site can be tested and also used from a testing user agent perspective;


Ref http://dojotoolkit.org/node/55
* To allow multiple variations and User Interface intepretations to the end-user UI, for example a future version of the application to have a stack of options and possibly layered user interface wrappers - for example a a mode to add accessibility customizations, for example zoom control, color manipulation to the theme, and more;


* Ability to fetch dynamic content and apply it to the current document;
* Have the CakePHP end to be completible with multiple AJAX client toolkits, and keep this compatibility layer via XHTML core User Interface layer - also referenced here as the semantic layer;
* Good for accessing additional interfaces in the Joey flow;
* Good for Next Previous buttons in a range list of dynamic retrieved elements;
* Pluses - comes with built in "Loading.. " state signal;
* Pluses - cache function , we may be able to store Previous panes in the list content
* Pluses - executeScripts true - can execute scripts loaded with the content.


==== Dojo Forms ====
* Log execution of a test case end-user flow, via dumping all the XHTML responses and REST queries.
 
http://dojotoolkit.org/node/59
 
* Form Bind - maps the traditional form to an XMLHTTPRequest. With this model, we can keep a FORM data in the client, and use it to create the transaction in the XHR channel. Would keep compability and probably would help us to keep the idea of an XHTML simplified + FORMS from CakePHP.
 
==== Dojo Events Connect ====
 
http://dojotoolkit.org/node/134
 
* Additional on Events http://dojotoolkit.org/node/88
* Dojo Events are general, for event flow control and an observation mechanism. Can be also used to listen to actual DOM UI events.
 
==== Dojo Undo ====
 
* In the Dojo package, check tests/undo for the iframe history control information.
 
==== Dojo dojo.xml.XslTransform ====


* ability to transform XML fragments in XML or XHTML fragments and attach to the docuemnt. This would be good if we want to keep some very lightweight encoded markup, then to transform in the dojo markup XHTML Div approach + classnames.
== XML Envelope and Cake Web Service Information ==


=== Considerations for the Joey Web Client ===
* http://wiki.mozilla.org/Labs/Joey/clients/ajaxy/server
* Back and Forward via Iframe history
* Strings binding via JSON or dynamic load of content panel ( or declarative strings markups delivered to the client from the CakePHP )


=== Architectural Goals ===
== Dojo development notes in the scope of CakePHP Joey ==


* To keep a simplified old school XHTML interface so that the Web site can be tested and also used from a testing user agent perspective.  
* http://wiki.mozilla.org/Labs/Joey/clients/ajaxy/dojojoey
* To allow multiple variations and User Interface intepretations to the end-user UI, for example a future version of the application to have a stack of options and possibly layered user interface wrappers - for example a a mode to add accessibility customizations, for example zoom control, color manipulation to the theme, and more.
* Be completible with multiple AJAX client toolkits, and keep this compatibility layer via XHTML core User Interface layer - also referenced here as the semantic layer.
* Log execution of a test case end-user flow, via dumping all the XHTML responses and REST queries.

Latest revision as of 22:50, 7 May 2007

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Design Overview - Joey AJAX Client

  • Not working on this! - e-mail mgalli@mgalli.com

Introduction

An aspect oriented design ( as a goal ) where CakePHP produces simplified XHTML data that is meaningful as an user interface. This interface shall be used by the Advanced Client - it could be described as an User Agent Interface. As we move forward, CakePHP content should be as semantic as possible, but at the same time we are to leave it as an 'old school' web interface, keeping its static links and forms as well. This approach should put us in a condition where the aspect of navigation and form interfaces is described separated from the Advanced AJAX navigation layer. This XHTML-based static structure should represent the navigational structure of the application. This should lead us to simplify maintenance in the CakePHP ( with simple and usable test pages ), automate tests with other tools that deals with traditional HTML page and forms. We may also simplify the usage other advanced ajax toolkit solutions.

Wishlist Architectural Aspects

  • _Accessibility for Navigation_ - Back and Forward buttons working via iframe history. Use it possibly for the main flows. We need to check if the mixture of Back/Forward working and not working conditions is a good or bad thing for the end-user. Since it is a AJAX UI, we may have some high very specific operations that are not to be registered in this iframe history;
  • _Accessibility for Legal_ - Keep partial compatibility with Robots indexing capability and keep the basic legal documents and overview linked from the main client document ( privacy, terms of use ) - we dont want people to need a full ajax client in order to read the terms. Check Dojo links so that the app has a compabible linking mechanism;
  • _Localization_ - Strings binding ( probably kicked with the initial document ) and additional flow-based sentences to be loaded in JSON or other XML binding approach;
  • _Accessibility for Usage_ - Check the story;
  • _Performance_ - build aspect. Check the Dojo build approach, and how to package partial Dojo components;
  • _Performance_ - Dojo ShrinkSafe;

Development Framework Considerations

  • To keep a simplified old school XHTML interface so that the Web site can be tested and also used from a testing user agent perspective;
  • To allow multiple variations and User Interface intepretations to the end-user UI, for example a future version of the application to have a stack of options and possibly layered user interface wrappers - for example a a mode to add accessibility customizations, for example zoom control, color manipulation to the theme, and more;
  • Have the CakePHP end to be completible with multiple AJAX client toolkits, and keep this compatibility layer via XHTML core User Interface layer - also referenced here as the semantic layer;
  • Log execution of a test case end-user flow, via dumping all the XHTML responses and REST queries.

XML Envelope and Cake Web Service Information

Dojo development notes in the scope of CakePHP Joey

Retrieved from "https://wiki.mozilla.org/index.php?title=Labs/Joey/clients/ajaxy/functional&oldid=56227"