|
You are here: Home / Bunch of requests
Bunch of requests
Forum /
Feature Requests /
Bunch of requests
Reply
Subscribe
Start new thread
Syndicated Feed (RSS)
|
Displaying 1 to 2 of 2
|
Previous
1
Next |
| Author |
Message |
ocrow
Posts: 2
|
We just launched a commercial deployment of Sitellite 4.2.0 Professional. As a whole our experience working with Sitellite (and Simian) was very positive. We did however run across some rough edges in the system, so here's my list of feature requests:
* The frame based design of the CMS caused confusion for the users and the designers. I would far rather have to add a "CMS header" box to every template than have to put up with the troubles of frames :-
1. hitting reload resets you to a different page
2. page URLs are masked in the browser bar by the frameset
3. inability to bookmark pages or copy a link to the current page, when you're logged into the CMS
* There's no obvious place to put site-wide customization code. I had to edit /index, which will complicate upgrades. There should be a hook for site-specific customization code that is executed from /index after the menu structure is created, but before document creation. This code could make changes to the $page object (or any other global objects), to affect all apps in the site.
* The SimpleTemplate module is very useful, but the documentation could be better. Needs examples of nested loops, extraction of data from arrays of arrays, arrays of objects, objects with object members, passing loop variable values into php code, using array values in conditionals, using object members in conditionals, when you need to use 'obj'., how to access a property of an object ({foo.bar} goes to foo in the global namespace, instead of obj.foo.bar).
* When using sitellite_filesystem app to download PDF files, the normal apache HTTP/1.1 handler is bypassed (as the request is handled by PHP), so partial document downloads are not supported (ie use of the HTTP Range header). The Acrobat PDF reader normally uses partial document downloads to display the initial page of a PDF and to enable navigation between pages before the entire PDF has downloaded. Without this support the entire PDF must be downloaded before any of it can be viewed. Also there is a bug in Acrobat 5 that causes it to occasionally wedge the browser, which only shows up when the web server doesn't acknowledge HTTP/1.1 Range headers. I suggest using a PHP HTTP/1.1 library such as PEAR HTTP_Download when responding to sitellite_filesystem requests to address these problems.
* In Xed it would be very useful if the current selection were maintained when switching between HTML and editor view and source view. That way you can quickly locate the source for a particular piece of HTML.
* Putting HTML 'keep out' code at the top of each box that isn't also a page makes for unneccessary code repetition, and makes the code harder to scan. Perhaps it would be better to put .htaccess files in each 'boxes' and 'forms' directory.
* It's hard to create a new MailForm that uses the tabbed pages layout like the edit/sitellite_page form. You have to customize javascript code for the form header (edit-top), and add custom php code to remove submitted pseudo-fields. Errors in javascript are hard to debug, and there's no documentation on how to do it right. There should be a standard widget set for creating a form like this that does the right thing.
* Using php code for the cancel buttons would be better than relying on Javascript. MailForm should have a member variable for where to return after you are done with a form, which can be overridden by the form itself. Then the Cancel button would call the standard MailForm cancel handler, instead of trying to validate the form contents. To do any necessary DB unlocking, one should override the cancel handler.
* Instead of each page including only the javascript items required for that page, there should be standard javascript library files included by all pages. That way (1) all the code is cached by the browser, and (2) the programmer doesn't have to worry about which functions to include in each form on a page by page basis.
* Moving the conf/collections/*.php files out of the 'cms' application and into the individual apps, would improve modularity and allow each app to define its own collections. Also, would be nice to have a way to enable/disable collections to keep the cms 'Content' pulldown short.
* Reference documentation for configuration files, esp. CMS Facets. is needed.
* The XT manual should describe the order of execution during page construction. e.g. I can run page_onload from a form, but not from a box. Why? When can boxes read global variables set by other boxes?
* Should allow a non versionned sitellite_filesystem. When you have large PDF files and a limited disk usage, storing old versions of files doesn't make sense. Lux provided a workaround that periodically deletes non-current versions of files from the filestore, but that still requires enough disk space to store each file twice -- once in the /inc/data folder and once in the /inc/app/cms/data/store filestore folder. It would be better if you could set sitellite_filesystem is_versioned = no. This doesn't work currently because the Source driver assumes the existence of the Store driver.
* The sitesearch indexer reindexes all documents every time it's run, but the Revision system knows the modification date on each document. Would be great to provide an incremental sitesearch indexer which reindexes only those documents which have changed since the last time the indexer was run. This would be especially useful given the slowness of updating Lucene's inverted index structures.
* Provide a configuration option for the permissions of created files. Use chmod in CGI/UploadedFile.php to set the permissions of uploaded files. (Otherwise uploaded files are created with web server user id, and may not be readable by a user logged into the shell).
* To make page caching useful, it needs to pay attention to the session. Otherwise edit buttons never show up on cached pages. You should be able to enable caching for users who are not logged in, and disable it for logged in users. That way the generic site is available (cached) to all, without any risk that per user customizations for logged in users are accidently published through the cache. Additionally the Cache needs to provide functions to clear the cache of a single page (e.g. when forms/edit/sitellite_page is submitted) or for all pages (e.g. when a database update that affects many pages is committed).
* Benchmarking shows that much of the time generating complex pages is spent in the SimpleTemplate template code. Adding a template cache that compiles templates to PHP code, similar to the one in Smarty, might increase page performance signficantly. It wouldn't have the implementation complexities of a page level cache and it would combine well with a PHP bytecode cache (e.g. APC or eaccelerator), because the template would then be compiled to bytecode.
Whew! Thanks again to Lux and the team. Looking forward to seeing how Sitellite continues to develop.
|
|
Back to top
|
|
justinw
Posts: 46
|
I've been developing with Sitellite for about two years now and I love it more and more all the time. There are just a couple things that I think would make it even better.
I'd like to officially second a few of ocrow's requests.
ocrow said:
* The SimpleTemplate module is very useful, but the documentation could be better. Needs examples of nested loops, extraction of data from arrays of arrays, arrays of objects, objects with object members, passing loop variable values into php code, using array values in conditionals, using object members in conditionals, when you need to use 'obj'., how to access a property of an object ({foo.bar} goes to foo in the global namespace, instead of obj.foo.bar).
I use SimpleTemplate quite a bit, and find myself often confused about how to access nested data inside a loop. I'm sure all the ingredients are there but often I can't figure out the syntax to access my data, even after a few hours of tinkering. So I give up and write a function that modifies the structure of my original data before I pass it to SimpleTemplate.
* Moving the conf/collections/*.php files out of the 'cms' application and into the individual apps, would improve modularity and allow each app to define its own collections. Also, would be nice to have a way to enable/disable collections to keep the cms 'Content' pulldown short.
This would be great! My convention currently is to keep an 'install' directory in my app's directory and symlink it to the conf/collections directory. That way I keep the original files bundled with my app, but they are still accessable the cms app.
|
|
Back to top
|
|
|
|
