Transaction methodologistics
The current version of Cassander (2.2RC3) uses templates to format data. These templates are processed by PHP and then sent to the client. The program currently uses a muxed retardation of AJAX and server-side processing. The main page is drawn once, by admin.php (or another page like login.php) and then each subsequent request (for each module) is handled in the same frame without refreshing the page. The frame itself is not a frame element, but a div that changes its contents. A problem arises from this method. When should admin.php draw the container frame and when should it just draw the inside content. A quick workaround was written for this to solve the issue but while it fixed the issue, it created more problems than it solved. Sometimes a page would need to be redraw (to refresh a cached page) and sometimes the same page would need to be drawn in the frame. This was solved by moving the "inside" check to the global header. If "inside" was sent to the server, it did not draw the outside frame because it is "inside". This became complicated because sometimes the page wouldn't know if it was inside or outside and the inside content couldn't talk to the outside content (because of scope resolution problems).
What if the content didn't need to specify inside or outside? What if the content could know automatically if it was inside or outside, and if it needed to call an inside or outside request? There are two ways that this can be accomplished. The first way requires no significant modification to the current infrastructure, but it does not facilitate growth or expansion very easily. The second method requires a very significant amount of change but will allow easier implementation of future features.
The first method
To track whether a request is inside or outside, append a pseudo-unique transaction ID to the end of each request by making a function that would be used to get data instead of doing it by hand each time. This transaction ID would track whether the request was INSIDE or OUTSIDE. Any subsequent request made by the current transaction would carry the inside flag.
The second method
Make one container for the site ("The wrapper"). The wrapper then requests data which is then returned via a JSON-style request. The data is then interpreted and printed on the site, no refreshing is ever done. Each request will return a template ID along with the data. If the template ID is not in the cache (There is a list of templates and ID's) then it will download the template and cache it. This way, the wrapper does not need to know how to draw data that it hasn't had to draw, but if it has to draw it again, it will be able to draw it again without asking for template data. This method moves Cassander towards being a total AJAX application.
Conclusion
Based on the information provided above, the second method is most appropriate. While it may take longer for this method to be implemented, it will allow for faster implementation of features down the road. The second method will provide a faster interface, better usability and an overall improvement on the current interface. Because the data will be sent in a generic format, it will allow for better third-party interpolation and integration.
What if the content didn't need to specify inside or outside? What if the content could know automatically if it was inside or outside, and if it needed to call an inside or outside request? There are two ways that this can be accomplished. The first way requires no significant modification to the current infrastructure, but it does not facilitate growth or expansion very easily. The second method requires a very significant amount of change but will allow easier implementation of future features.
The first method
To track whether a request is inside or outside, append a pseudo-unique transaction ID to the end of each request by making a function that would be used to get data instead of doing it by hand each time. This transaction ID would track whether the request was INSIDE or OUTSIDE. Any subsequent request made by the current transaction would carry the inside flag.
The second method
Make one container for the site ("The wrapper"). The wrapper then requests data which is then returned via a JSON-style request. The data is then interpreted and printed on the site, no refreshing is ever done. Each request will return a template ID along with the data. If the template ID is not in the cache (There is a list of templates and ID's) then it will download the template and cache it. This way, the wrapper does not need to know how to draw data that it hasn't had to draw, but if it has to draw it again, it will be able to draw it again without asking for template data. This method moves Cassander towards being a total AJAX application.
Conclusion
Based on the information provided above, the second method is most appropriate. While it may take longer for this method to be implemented, it will allow for faster implementation of features down the road. The second method will provide a faster interface, better usability and an overall improvement on the current interface. Because the data will be sent in a generic format, it will allow for better third-party interpolation and integration.
