Thread: [Phpslash-devel] phpSlash Roadmap discussuon
Brought to you by:
joestewart,
nhruby
Menu
▾
▴
phpslash-devel
|
From: Joe S. <joe...@us...> - 2004-09-16 20:17:57
|
phpSlash is not dead, maybe moving slow, but not dead. The Back-End folks, led by Mike Gifford have been making lots of progress. The psl 0.8 release cycle is about to speed up. I'm planning on another beta test, then when that proves fairly stable, get a release candidate out. I do not want a long release cycle on this. Most everything here has been proven. I'd like to update the phpSlash Roadmap to be something that we can work toward. For psl 0.8: - needs a printer css or printer friendly view. - the wap article pages are not available anymore either. Both of these could be added back using the old code, but I'd like to see them improved. - I'd like to see someone familiar with phplist to configure it for a default setup to mimic our current headline mailer. Then we could just drop the current code. The phplist module is included in the current beta. - there is a css issue in the phplist admin page I haven't debugged. - What skins should be included in the main download? - What modules should be included? - Anything else? For psl 0.9: Not an exhaustive list or even looking at the current Roadmap. bring as much that BE has developed into psl as needed. - subsections - sitemap - subsites - block caches - trackback - multi language - what else? Move old stuff like glossary, etc. out of the core? How much should be released with the core? Move the templates to a subdirectory of the module. This is supported now. But I'd like to get 0.8 out first. module install, register, update, remove method - including db setup, other required modules and version(s) required. Navbar administration? - This shouldn't be too bad. We can generate the navbars once per session/authentication cycle couldn't we? Oh, enough for now. Maybe we can discuss this on irc as well. Joe |
|
From: Peter C. <li...@cr...> - 2004-09-18 09:35:13
|
On Thu, 16 Sep 2004 12:41:57 -0500 Joe Stewart <joe...@us...> wrote: > phpSlash is not dead, maybe moving slow, but not dead. The Back-End > folks, led by Mike Gifford have been making lots of progress. > > The psl 0.8 release cycle is about to speed up. I'm planning on another > beta test, then when that proves fairly stable, get a release candidate > out. I do not want a long release cycle on this. Most everything here > has been proven. I've been using the alpha code for a while on a couple of sites with no major problems. > I'd like to update the phpSlash Roadmap to be something that we can work > toward. Excellent! I've split my thoughts on 0.9 into a separate email > For psl 0.8: > > - needs a printer css or printer friendly view. Yup > - the wap article pages are not available anymore either. How much is this used - is this a show-stopper? > Both of these could be added back using the old code, but I'd like to > see them improved. > > - I'd like to see someone familiar with phplist to configure it for a > default setup to mimic our current headline mailer. Then we could just > drop the current code. The phplist module is included in the current > beta.- there is a css issue in the phplist admin page I haven't debugged. phpList might be a excessive for the situation where there are only a few people signing up, and only basic functionality is required. Just a thought. > - What skins should be included in the main download? > - What modules should be included? The ones I think it might sense to drop/turn off are glossary and poll. comment might also be optional, but it's still hardwired in places in the code, so we're stuck with it for now. If some modules are NOT included, there needs to be some pretty clear instructions on how to download them and add them. > - Anything else? I wonder if this is a good point to create a new default database? As for skins, I clearly have a bias towards ShankZen! But it would be good to move to consistent use of style names. eg Where ShankZen uses "psl-desc", basic uses "desc". I think the "psl-" prefix is good, because it avoids namespace clashes with external modules... I'd be happy to update basic if you agree. ShankZen's stylesheets could probably be simplified a little; again, I'd be happy to do this. I've got other CSS files that can be applied to ShankZen's templates. Would you be interested? How would they be included in a distribution? P |
|
From: Joe S. <joe...@us...> - 2004-09-18 11:39:53
|
On Sat, Sep 18, 2004 at 10:45:30AM +0100, Peter Cruickshank wrote: > On Thu, 16 Sep 2004 12:41:57 -0500 > Joe Stewart <joe...@us...> wrote: > > > phpSlash is not dead, maybe moving slow, but not dead. The Back-End > > folks, led by Mike Gifford have been making lots of progress. > > > > The psl 0.8 release cycle is about to speed up. I'm planning on another > > beta test, then when that proves fairly stable, get a release candidate > > out. I do not want a long release cycle on this. Most everything here > > has been proven. > > I've been using the alpha code for a while on a couple of sites with no > major problems. > me too. php-slash.org is now on the latest -dev snapshot release. I kinda hope the Wiki will turn into something similar to http://manual.back-end.org. I do like the current manual configuration on the site to allow comments, etc. We can even open up editing privileges to be available publicly like a wiki. Our rollback is cvs. > > I'd like to update the phpSlash Roadmap to be something that we can work > > toward. > > Excellent! I've split my thoughts on 0.9 into a separate email > > > For psl 0.8: > > > > - needs a printer css or printer friendly view. > Yup > > - the wap article pages are not available anymore either. > How much is this used - is this a show-stopper? > not a big problem to me. > > Both of these could be added back using the old code, but I'd like to > > see them improved. > > > > - I'd like to see someone familiar with phplist to configure it for a > > default setup to mimic our current headline mailer. Then we could just > > drop the current code. The phplist module is included in the current > > beta.- there is a css issue in the phplist admin page I haven't debugged. > > phpList might be a excessive for the situation where there are only a few > people signing up, and only basic functionality is required. Just a > thought. > Probably true. My concern is maintaing the existing code. If our efforts are to maintain a phplist module instead, it seems to be a better use of resources. > > - What skins should be included in the main download? > > - What modules should be included? > The ones I think it might sense to drop/turn off are glossary and poll. > comment might also be optional, but it's still hardwired in places in the > code, so we're stuck with it for now. > glossary is the one in particular I had in mind. The comments are almost to the point there could be other software used for this too. The Comments code is getting pretty long in the tooth. Ajay worked on the Comments and Poll. No one has adopted them since he moved on. > If some modules are NOT included, there needs to be some pretty clear > instructions on how to download them and add them. > This is true across the board. > > - Anything else? > > I wonder if this is a good point to create a new default database? > Yes. I've been thinking of splitting it out to two sql files - one core and one example data. > As for skins, I clearly have a bias towards ShankZen! But it would be good > to move to consistent use of style names. eg Where ShankZen uses > "psl-desc", basic uses "desc". I think the "psl-" prefix is good, because > it avoids namespace clashes with external modules... I'd be happy to update > basic if you agree. > a volunteer! great! How about a printer css? Most of the skins that I ported kept all their style names instead of conforming to your convention. > ShankZen's stylesheets could probably be simplified a little; again, I'd be > happy to do this. > There is an issue with the ShankZend htmlarea3 and one of the stylesheets now I think. This may have been resolved. > I've got other CSS files that can be applied to ShankZen's templates. > Would you be interested? How would they be included in a distribution? > Good question. At the very least - create a ShankZen directory in the styles ( like BE_Default) put all your stylesheets there. Put them in the header so that they can be chosen in the browser. This would get them included and show they could be used in the header template as needed. thanks, Joe > P > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel |
|
From: Joe S. <joe...@us...> - 2004-09-27 14:41:06
|
on 09/18/04 06:39 Joe Stewart said the following: > On Sat, Sep 18, 2004 at 10:45:30AM +0100, Peter Cruickshank wrote: > >>On Thu, 16 Sep 2004 12:41:57 -0500 >>Joe Stewart <joe...@us...> wrote: >> >> <snip> > > >>I've got other CSS files that can be applied to ShankZen's templates. >>Would you be interested? How would they be included in a distribution? >> > > > Good question. > > At the very least - > > create a ShankZen directory in the styles ( like BE_Default) > put all your stylesheets there. > Put them in the header so that they can be chosen in the browser. > Well I didn't know that the stylesheet chooser had been removed from Firefox. It is nice to be able to choose from a list of stylesheets the designer makes available. Hopefully there will be an extension soon or the bugs fixed and it return. > This would get them included and show they could be used in the header template as > needed. > I'm bringing in a bunch of tiki templates much the same way. I think we can add a CSS tag and check if it is available. If not, stuff it with the SKIN name. What do you think? Joe |
|
From: Joe S. <joe...@us...> - 2004-10-19 20:11:44
|
on 09/18/04 06:39 Joe Stewart said the following: > On Sat, Sep 18, 2004 at 10:45:30AM +0100, Peter Cruickshank wrote: > >>On Thu, 16 Sep 2004 12:41:57 -0500 >>Joe Stewart <joe...@us...> wrote: >> <snip> > >>>- Anything else? >> >>I wonder if this is a good point to create a new default database? >> > > > Yes. I've been thinking of splitting it out to two sql files - one core and one > example data. > Got it split here. Working on getting the installer to grab the example data too now. > >>As for skins, I clearly have a bias towards ShankZen! But it would be good >>to move to consistent use of style names. eg Where ShankZen uses >>"psl-desc", basic uses "desc". I think the "psl-" prefix is good, because >>it avoids namespace clashes with external modules... I'd be happy to update >>basic if you agree. >> > > > a volunteer! great! > > How about a printer css? > I committed a ShankZen_print.css but it's broken. There were some parts that still wanted to be shown. Maybe you can fix quickly in a way that won't break your other css files. > Most of the skins that I ported kept all their style names instead of conforming to > your convention. > > >>ShankZen's stylesheets could probably be simplified a little; again, I'd be >>happy to do this. >> > > > There is an issue with the ShankZend htmlarea3 and one of the stylesheets now I > think. This may have been resolved. > The ShankZen_ext.css has something that was interfering with the htmlarea displaying. I didn't investigate further. > >>I've got other CSS files that can be applied to ShankZen's templates. >>Would you be interested? How would they be included in a distribution? >> > I created a phpslash-skins/public_html/styles/ShankZen directory. Add them there. > > Good question. > > At the very least - > > create a ShankZen directory in the styles ( like BE_Default) > put all your stylesheets there. > Put them in the header so that they can be chosen in the browser. > > This would get them included and show they could be used in the header template as > needed. > Adding a few in the header would let Mozilla users change them. This was evidently taken out of Firefox. Anybody know of an extension? Joe > > thanks, > > Joe > > > >>P |
|
From: Peter C. <pe...@cr...> - 2004-09-18 09:35:33
|
I split of my 0.9 thoughts because there seem to be a lot of them... On Thu, 16 Sep 2004 12:41:57 -0500 Joe Stewart <joe...@us...> wrote: > For psl 0.9: > > Not an exhaustive list or even looking at the current Roadmap. > > bring as much that BE has developed into psl as needed. > - subsections Yes!! > - sitemap > - subsites How often would this be needed? Back-End might be more suitable solution for sites that are big enough to need subsites. > - block caches > - trackback > - multi language > - what else? A thought: Allow for switching CSS while keeping the same skin without using a dummy template directory + skin.ini > Move old stuff like glossary, etc. out of the core? Makes sense. Having said that, space is probably not an issue. So maybe just have glossary etc turned off by default. > How much should be released with the core? > > Move the templates to a subdirectory of the module. This is supported > now. But I'd like to get 0.8 out first. Makes sense > module install, register, update, remove method - including db setup, > other required modules and version(s) required. Definitely. > Navbar administration? - This shouldn't be too bad. We can generate the > navbars once per session/authentication cycle couldn't we? Definitely too. The current menu-config setup is not end-user friendly at all... > Oh, enough for now. Here's my initial thoughts: PSL does a lot, but in a lot of places it's really ugly, and there's a lot of legacy code lurking around. I think a lot of the work in the 0.9 cycle should be focussed not on adding new features (PSL has already got a lot), but making existing features more accessible/ understandable. Areas could include: A. Improvements to interface/interaction Interface cleanup and/or redesign, particularly around block and section administration (it should be possible to position blocks from the section admin screen). Seagull (http://seagull.phpkitchen.com/) seems to have put a lot of thought into their UI - with the result that a less functional application- framework looks like it can do more than PSL. We may have to find some design type person to take some of this on. B. Updated user documentation Back-End's wiki manual has worked well (http://manual.back-end.org/) - maybe we could do the same with phpSlash? Good, clear instructions on troubleshooting the installation of a new module should be a high priority! C. Cleaning up code It would be nice to separate the data access, presentation and business logic more consistently. From my experience with Back-End, it would be good to do this *before* adding in new features like subsites and multi-lingualness. (Moving to a compiling/caching template system like smarty or Flexy might be worth thinking about). There's a fair bit of duplicated code lurking around too (eg compare Story::getStory() and Story::getStories()). Other stuff that comes to mind are adding common datetime handling throughout the code (could be lifted from Back-End) While we're at it, we could add consistent phpDoc comments, and make the output available online somewhere. And finally, there's XHTML compliant templates (and documentation of the classes that are used - I've made a start on this but there's nowhere to put that right now - see below) D. Move to PEAR (controversial?) phplib provides a stable codebase, but development has pretty well stopped. I have a feeling that it will make sense (at some point in the future - possibly before PHP5 becomes the standard) to move to using PEAR db, template and security handling at some point. On the other hand, if it ain't broke... > Maybe we can discuss this on irc as well. Good idea. I'd like to participate, timezones permitting. Peter |
|
From: Joe S. <joe...@us...> - 2004-09-18 12:12:18
|
On Sat, Sep 18, 2004 at 10:45:50AM +0100, Peter Cruickshank wrote: > I split of my 0.9 thoughts because there seem to be a lot of them... > > On Thu, 16 Sep 2004 12:41:57 -0500 > Joe Stewart <joe...@us...> wrote: > > > For psl 0.9: > > > > Not an exhaustive list or even looking at the current Roadmap. > > > > bring as much that BE has developed into psl as needed. > > - subsections > Yes!! > I'm not sure about implementing exactly the same, but this feature is sorely needed. > > - sitemap > > > - subsites > How often would this be needed? Back-End might be more suitable solution > for sites that are big enough to need subsites. > good point. Just throwing stuff out. > > > - what else? > - pagination - I can't believe I forgot this one. - user page redesign - I like the author list in BE. > A thought: Allow for switching CSS while keeping the same skin without > using a dummy template directory + skin.ini > That is the current method. A css switcher block would be nice. > > Move old stuff like glossary, etc. out of the core? > > Makes sense. Having said that, space is probably not an issue. So maybe > just have glossary etc turned off by default. > Will do that for now. I don't think many people actually put it to good use. With all the skins we are at about 2 meg. Adding phplist makes it about 3meg. > > How much should be released with the core? > > > > Move the templates to a subdirectory of the module. This is supported > > now. But I'd like to get 0.8 out first. > > Makes sense > > > module install, register, update, remove method - including db setup, > > other required modules and version(s) required. > > Definitely. > > > Navbar administration? - This shouldn't be too bad. We can generate the > > navbars once per session/authentication cycle couldn't we? > > Definitely too. The current menu-config setup is not end-user friendly at > all... > I've been looking at tiki's menu admin - pretty nice. > > > Oh, enough for now. > > Here's my initial thoughts: > > PSL does a lot, but in a lot of places it's really ugly, and there's a lot > of legacy code lurking around. I think a lot of the work in the 0.9 cycle > should be focussed not on adding new features (PSL has already got a lot), > but making existing features more accessible/ understandable. > I get surprised sometimes seeing some of the legacy code. > Areas could include: > > A. Improvements to interface/interaction > Interface cleanup and/or redesign, particularly around block and section > administration (it should be possible to position blocks from the section > admin screen). > > Seagull (http://seagull.phpkitchen.com/) seems to have put a lot of thought > into their UI - with the result that a less functional application- > framework looks like it can do more than PSL. > > We may have to find some design type person to take some of this on. > > > B. Updated user documentation > Back-End's wiki manual has worked well (http://manual.back-end.org/) - > maybe we could do the same with phpSlash? > ah. I didn't see this before my other response. I installed a wiki already on php-slash.org but don't have much experience. > Good, clear instructions on troubleshooting the installation of a new > module should be a high priority! > I guess that might be me (: > > C. Cleaning up code > It would be nice to separate the data access, presentation and business > logic more consistently. From my experience with Back-End, it would be good > to do this *before* adding in new features like subsites and > multi-lingualness. > Thanks for bringing this up. eGroupware has this architecture. They use ui, bo, and db as there separation. dcl uses almost the same nomenclature. I'll probably add this to sf.net RFE pronto. > (Moving to a compiling/caching template system like smarty or Flexy might > be worth thinking about). > maybe so. Anyone seen any recent benchmarks? The last I saw still showed phplib templates faster. Curious if the phplib templates in PEAR bear this out as well. > There's a fair bit of duplicated code lurking around too (eg compare > Story::getStory() and Story::getStories()). Other stuff that comes to mind > are adding common datetime handling throughout the code (could be lifted > from Back-End) > > While we're at it, we could add consistent phpDoc comments, and make the > output available online somewhere. > I used to generate this and make it available. Here is the link for -ft: http://www.php-slash.org/phpdoc/phpslash-ft/ > And finally, there's XHTML compliant templates (and documentation of the > classes that are used - I've made a start on this but there's nowhere to > put that right now - see below) > > > > D. Move to PEAR (controversial?) > phplib provides a stable codebase, but development has pretty well stopped. > I have a feeling that it will make sense (at some point in the future - > possibly before PHP5 becomes the standard) to move to using PEAR db, > template and security handling at some point. On the other hand, if it > ain't broke... > I'm torn on this. I've found some versioning issues with PEAR. It's nice for us including phplib now. There has been talk of rewriting parts of phplib for php5 support. > > > Maybe we can discuss this on irc as well. > > Good idea. I'd like to participate, timezones permitting. > You don't seem to sleep anyway. Joe > Peter > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X