| Lines 19 - 21 |
Lines 19 - 48 |
| Approval would also be filtered. If a user has approval, but then only has rights to Article Manager, but not Blockmaker or Calendar, then that user only sees Articles in his her group to approve. It would act more like a filter than a restriction, show the user with approval only the content they need to see. In essence managing the content better. |
Approval would also be filtered. If a user has approval, but then only has rights to Article Manager, but not Blockmaker or Calendar, then that user only sees Articles in his her group to approve. It would act more like a filter than a restriction, show the user with approval only the content they need to see. In essence managing the content better. |
| |
|
| Currently Calendar items get posted accross groups? René has re-written the Calendar module to allow it to filter by category. In this regard, the Calendar should behave in the exact same manner as Articles, Blocks, Announcements or Webpages. Why Groups are brought into this seems a mystery. Categories should be the driving force behind ALL content. |
Currently Calendar items get posted accross groups? René has re-written the Calendar module to allow it to filter by category. In this regard, the Calendar should behave in the exact same manner as Articles, Blocks, Announcements or Webpages. Why Groups are brought into this seems a mystery. Categories should be the driving force behind ALL content. |
| |
|
| |
|
| |
++ phpWebSite as an application frame work |
| |
|
| |
The developement team is proud of its code. And it should be. Since the initial release 0.6, every major phpWebSite release involved a big rewrite of the core. Modules of 0.8 for example are not compatible to 0.9. |
| |
|
| |
Still there is enough room for improvement. One might think that there is not enough developement capacity for the core. Different to most known open source projects, open patches can be found for as long as [http://sourceforge.net/tracker/index.php?func=detail&aid=769842&group_id=15539&atid=315539 2 years ago]. The status of patches is unclear, some seem to be included in the core already but one cannot tell for sure. |
| |
|
| |
+++ Developing new modules |
| |
|
| |
Developing new modules is a tendious task. For the most basic functions, like showing tabular data in lists, there are a lot of different APIs that are incompatible to each other. You want to do a html-form? Choose one of three different approaches. The not-yet-scheduled 1.0 release of phpWebSite will be incompatible to the current apis but have a compatibility layer. |
| |
|
| |
The APIs is not final, so technically speaking phpWebSite is still Alpha (not even Beta) -- far away from a productive release. Am I unpatient? Maybe. |
| |
|
| |
Fact is, no API means a discouraging of module developement. And applications are -- in a similar manner like ease of use -- what most people want to use software for. |
| |
|
| |
+++ Top Down approach |
| |
|
| |
Right now, it seems that phpWebSite is developed from a bottom-up approach. There are experiments regarding the core, APIs are rewritten all the time and there is no current documentation. Writing new documentation is also pointless, so is serious module developement. |
| |
|
| |
A different approach would be top-down. There would be one API, roughly implemented and ready to use for all developers. Modules would be written in parallel to the core developement. The core would be improved all the time under the hood and at the same time, wonderful new modules would be created. |
| |
|
| |
This approach would require a stable, easy to use but yet flexible API (not a stable core). The easier the API is to use (and I am not writing about performance here) the more it would encourage people to write modules. A good API with a good documentation would allow good modules. |
| |
|
| |
Not hacked ones like seen all over phpWebSite which implement centralized features all over again. |
| |
|
| |
|
FutureOfPhpWebSite
