On Tue, Mar 29, 2011 at 2:53 PM, alex bodnaru <[email protected]> wrote: > > hello friends, > > after an effort to enhance tgext.pages, i'd like to invest the experience i've > gained into acr cms, which is more professionally designed, and yet it has to > be > improved. >
Hi Alex, As ACR was born as a project to quickly solve our own needs I'm aware of the fact that it has large space for improvements. I'm really open to any suggestion about how it can be improved. First of all it is probably missing a more "community driven" style. But as the only developers committing on it were at axant I never spent my time to move the project somewhere else. Probably Sourceforge should be the chosen place for TG related projects. > acr-0.2.2 sthould depend on stroller and on SQLAlchemy >= 0.6.6; Uhm, actually as I'm not the one who prepared the stable releases I can't remember what there is on the 0.2.2 release. I suggest you to use the mercurial repository version from the "acr" branch. We usually try to keep a stable version there. stroller should not be a required dependency, if it is missing it should simple continue to work without the eCommerce plugin. > the preloaded example should contain some slices for the main section too. > a section should have a border and a top bar in edit mode, like slices, and a > button to allow adding a slice to the section. If I remembered well the default setup should actually create two slices inside the main section for the index page. Am I wrong? To add slices somewhere in page you should be able to use the "ADD SLICE" menu from top. > i've made tw.tinymce3 and it's in bitbucket. soon in pypi. > the special slices editable in acr should also be embeddable in html slices, > definitely through selection lists available in tw.tinymce api. a working > example in tgext.pages. Uhm, I didn't understand, can you try to explain it? > deleting a page should delete it's slices, after special confirmation, of > course. This makes sense, currently slices are left inside the Unbound Entities admin page, but deleting them makes more sense. > in page edit form, only the page itself should be selectable. a tree control > might improve readability, at least a selection box with optgroups, or, last > of > the least, joining a page's name with it's ancestors. What do you mean about "only the page itself should be selectable"? Are you talking abou the Page->ParentPage relation? > page names should be unique only within their parents, so that > /home/alex/hobbies could coexist with /home/mark/hobbies. > This makes sense, as said before we always improved ACR for our own needs and so we left behind a lot of improvements which seem obvious to a new user. > i'd be willing to help. > Your help and suggestions are really appreciated. I'm thinking about moving the project on Bitbucket or SF.net so that it should be easy to fork it and propose changes. -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
