Menu
▾
▴
phpicalendar-devel
|
From: David F. <da...@d2...> - 2005-05-20 22:53:46
|
Ugh, the switch to not using forms openevent stuff was a can o' worms. This would be vastly easier if we used a real template system - is there a reason we're not using one of the template classes from PEAR? (http://pear.php.net/manual/en/package.html.php) I've used HTML_TEMPLATE_IT, and it works well and the syntax is almost identical (in the template) to what's already there. The code syntax is significantly different, of course, since all the "hard work" (the various regexes all over the place) is abstracted out for you. :) While I should learn my lesson after diving into this rewrite, I volunteer myself to do the switchover if I get approval. This, of course, is a fairly serious rewrite, but continues my "less code" mantra. I have probably a day or two left in the form stuff, so I should commit sometime early next week, jim. Although writing this has remotivated me, so I'll see if I can finish today. I then have my two bugs to fix (the guaranteed-unique uids, and fixing the year render window), and I'll probably stop bugfixing until people start complaining of broken things, or we get a release out - the remaining stuff I'd like to do is even more "not for just before release" than this stuff. So, please give me some bugs to fix. :) dave |
|
From: Jake S. <ns...@us...> - 2005-05-21 05:17:29
|
David Fallon wrote: > Ugh, the switch to not using forms openevent stuff was a can o' worms. > This would be vastly easier if we used a real template system - is there > a reason we're not using one of the template classes from PEAR? > (http://pear.php.net/manual/en/package.html.php) I've used > HTML_TEMPLATE_IT, and it works well and the syntax is almost identical > (in the template) to what's already there. The code syntax is > significantly different, of course, since all the "hard work" (the > various regexes all over the place) is abstracted out for you. :) While > I should learn my lesson after diving into this rewrite, I volunteer > myself to do the switchover if I get approval. This, of course, is a > fairly serious rewrite, but continues my "less code" mantra. > > I have probably a day or two left in the form stuff, so I should commit > sometime early next week, jim. Although writing this has remotivated me, > so I'll see if I can finish today. I then have my two bugs to fix (the > guaranteed-unique uids, and fixing the year render window), and I'll > probably stop bugfixing until people start complaining of broken things, > or we get a release out - the remaining stuff I'd like to do is even > more "not for just before release" than this stuff. So, please give me > some bugs to fix. :) > > dave > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel Have you had a look at smarty.php.net? We used to use HTML_TEMPLATE_IT but smarty has some neat features such as caching that make things faster and other nifty features that make templating easier Jake |
|
From: <da...@d2...> - 2005-05-21 18:12:11
|
> David Fallon wrote: >> Ugh, the switch to not using forms openevent stuff was a can o' worms. >> This would be vastly easier if we used a real template system - is there >> a reason we're not using one of the template classes from PEAR? >> (http://pear.php.net/manual/en/package.html.php) I've used >> HTML_TEMPLATE_IT, and it works well and the syntax is almost identical >> (in the template) to what's already there. The code syntax is >> significantly different, of course, since all the "hard work" (the >> various regexes all over the place) is abstracted out for you. :) While >> I should learn my lesson after diving into this rewrite, I volunteer >> myself to do the switchover if I get approval. This, of course, is a >> fairly serious rewrite, but continues my "less code" mantra. > > Have you had a look at smarty.php.net? We used to use HTML_TEMPLATE_IT > but smarty has some neat features such as caching that make things > faster and other nifty features that make templating easier I haven't looked at it much, but I will take a closer look. In my brief 5 sec. glance after your email, two concerns jumped out - the syntax is decently different than the existing template stuff in phpicalendar (while html_template_it is almost identical), and it's not integrated into php/pear, meaning we'd have to have an additional install requirement. The second one being the bigger of the two, since I'd definitely recommend staying away from any additional install requirements. |
|
From: Chad L. <ch...@ch...> - 2005-05-21 19:30:57
|
We're not really interested in a templating add-on that would require PEAR or Smarty. Smarty is bloated and really overkill for the project. Writing our own template engine presented a way to provide the fastest method of displaying content and allowing users to tweak the code with little php knowledge. -C On May 21, 2005, at 11:12 AM, da...@d2... wrote: >> David Fallon wrote: >> >>> Ugh, the switch to not using forms openevent stuff was a can o' >>> worms. >>> This would be vastly easier if we used a real template system - >>> is there >>> a reason we're not using one of the template classes from PEAR? >>> (http://pear.php.net/manual/en/package.html.php) I've used >>> HTML_TEMPLATE_IT, and it works well and the syntax is almost >>> identical >>> (in the template) to what's already there. The code syntax is >>> significantly different, of course, since all the "hard work" (the >>> various regexes all over the place) is abstracted out for you. :) >>> While >>> I should learn my lesson after diving into this rewrite, I volunteer >>> myself to do the switchover if I get approval. This, of course, is a >>> fairly serious rewrite, but continues my "less code" mantra. >>> >> >> Have you had a look at smarty.php.net? We used to use >> HTML_TEMPLATE_IT >> but smarty has some neat features such as caching that make things >> faster and other nifty features that make templating easier >> > > I haven't looked at it much, but I will take a closer look. In my > brief 5 > sec. glance after your email, two concerns jumped out - the syntax is > decently different than the existing template stuff in phpicalendar > (while > html_template_it is almost identical), and it's not integrated into > php/pear, meaning we'd have to have an additional install > requirement. The > second one being the bigger of the two, since I'd definitely recommend > staying away from any additional install requirements. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
|
From: <da...@d2...> - 2005-05-22 00:47:49
|
Hmm, okay. What can I do to convince you otherwise? HTML_TEMPLATE_IT is veeery similar to what's already happening, but with two benefits - a standardized way of doing the template code, and simpler "loop" support, which currently is done in a bunch of different ways, including having the html included in the php code which lessens the usefulness of the template. If I rewrote draw_day/day.tmpl to show you the difference (and gave you some performance numbers, which should be roughly the same or maybe even better)? > We're not really interested in a templating add-on that would require > PEAR or Smarty. Smarty is bloated and really overkill for the > project. Writing our own template engine presented a way to provide > the fastest method of displaying content and allowing users to tweak > the code with little php knowledge. > > -C > > > On May 21, 2005, at 11:12 AM, da...@d2... wrote: > >>> David Fallon wrote: >>> >>>> Ugh, the switch to not using forms openevent stuff was a can o' >>>> worms. >>>> This would be vastly easier if we used a real template system - >>>> is there >>>> a reason we're not using one of the template classes from PEAR? >>>> (http://pear.php.net/manual/en/package.html.php) I've used >>>> HTML_TEMPLATE_IT, and it works well and the syntax is almost >>>> identical >>>> (in the template) to what's already there. The code syntax is >>>> significantly different, of course, since all the "hard work" (the >>>> various regexes all over the place) is abstracted out for you. :) >>>> While >>>> I should learn my lesson after diving into this rewrite, I volunteer >>>> myself to do the switchover if I get approval. This, of course, is a >>>> fairly serious rewrite, but continues my "less code" mantra. >>>> >>> >>> Have you had a look at smarty.php.net? We used to use >>> HTML_TEMPLATE_IT >>> but smarty has some neat features such as caching that make things >>> faster and other nifty features that make templating easier >>> >> >> I haven't looked at it much, but I will take a closer look. In my >> brief 5 >> sec. glance after your email, two concerns jumped out - the syntax is >> decently different than the existing template stuff in phpicalendar >> (while >> html_template_it is almost identical), and it's not integrated into >> php/pear, meaning we'd have to have an additional install >> requirement. The >> second one being the bigger of the two, since I'd definitely recommend >> staying away from any additional install requirements. >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by Oracle Space Sweepstakes >> Want to be the first software developer in space? >> Enter now for the Oracle Space Sweepstakes! >> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > > |
|
From: Chad L. <ch...@ch...> - 2005-05-22 19:39:26
|
I guess I don't understand why we'd switch template engines, confusing longtime users (and the templates they have already made), for minimal added benefit. I also don't know why we'd add dependencies into PHP iCalendar (checking for pear, etc) that could introduce bugs or other unknown issues. I know there is still HTML in the template engine, and it was always my goal to pull it completely out, unfortunately I didn't have then time needed to complete that area and spent it on getting everything moved over. -C On May 21, 2005, at 5:47 PM, da...@d2... wrote: > Hmm, okay. What can I do to convince you otherwise? > HTML_TEMPLATE_IT is > veeery similar to what's already happening, but with two benefits - a > standardized way of doing the template code, and simpler "loop" > support, > which currently is done in a bunch of different ways, including > having the > html included in the php code which lessens the usefulness of the > template. If I rewrote draw_day/day.tmpl to show you the difference > (and > gave you some performance numbers, which should be roughly the same or > maybe even better)? > > >> We're not really interested in a templating add-on that would require >> PEAR or Smarty. Smarty is bloated and really overkill for the >> project. Writing our own template engine presented a way to provide >> the fastest method of displaying content and allowing users to tweak >> the code with little php knowledge. >> >> -C >> >> >> On May 21, 2005, at 11:12 AM, da...@d2... wrote: >> >> >>>> David Fallon wrote: >>>> >>>> >>>>> Ugh, the switch to not using forms openevent stuff was a can o' >>>>> worms. >>>>> This would be vastly easier if we used a real template system - >>>>> is there >>>>> a reason we're not using one of the template classes from PEAR? >>>>> (http://pear.php.net/manual/en/package.html.php) I've used >>>>> HTML_TEMPLATE_IT, and it works well and the syntax is almost >>>>> identical >>>>> (in the template) to what's already there. The code syntax is >>>>> significantly different, of course, since all the "hard work" (the >>>>> various regexes all over the place) is abstracted out for you. :) >>>>> While >>>>> I should learn my lesson after diving into this rewrite, I >>>>> volunteer >>>>> myself to do the switchover if I get approval. This, of course, >>>>> is a >>>>> fairly serious rewrite, but continues my "less code" mantra. >>>>> >>>>> >>>> >>>> Have you had a look at smarty.php.net? We used to use >>>> HTML_TEMPLATE_IT >>>> but smarty has some neat features such as caching that make things >>>> faster and other nifty features that make templating easier >>>> >>>> >>> >>> I haven't looked at it much, but I will take a closer look. In my >>> brief 5 >>> sec. glance after your email, two concerns jumped out - the >>> syntax is >>> decently different than the existing template stuff in phpicalendar >>> (while >>> html_template_it is almost identical), and it's not integrated into >>> php/pear, meaning we'd have to have an additional install >>> requirement. The >>> second one being the bigger of the two, since I'd definitely >>> recommend >>> staying away from any additional install requirements. >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by Oracle Space Sweepstakes >>> Want to be the first software developer in space? >>> Enter now for the Oracle Space Sweepstakes! >>> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >>> _______________________________________________ >>> Phpicalendar-devel mailing list >>> Php...@li... >>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >>> >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by Oracle Space Sweepstakes >> Want to be the first software developer in space? >> Enter now for the Oracle Space Sweepstakes! >> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> >> >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
|
From: David F. <da...@d2...> - 2005-05-23 17:30:20
|
Fair enough, I'll do some work putting together an example of why using the PEAR one is nicer. The short answer is for the end user, it's basically irrelevant (the template format is almost identical) besides the side benefit of moving more HTTML out to the templates. For developers, however, it's much nicer because it abstracts out the template engine nicely, and is more full-featured than the current "engine". Plus, using an abstracted model lets us standardize the code, where now lots of the template "engine" stuff is done in different ways or has different features depending on who did it, and when. Heck, if it's the dependancy on the PEAR stuff that's the issue, we can always copy the code out and include it in phpicalendar (I think there isn't any licensing isssues). I'll have to check, but I think you get PEAR by default now, though. Chad Little wrote: > I guess I don't understand why we'd switch template engines, confusing > longtime users (and the templates they have already made), for minimal > added benefit. I also don't know why we'd add dependencies into PHP > iCalendar (checking for pear, etc) that could introduce bugs or other > unknown issues. > > I know there is still HTML in the template engine, and it was always my > goal to pull it completely out, unfortunately I didn't have then time > needed to complete that area and spent it on getting everything moved > over. > > -C > > > On May 21, 2005, at 5:47 PM, da...@d2... wrote: > >> Hmm, okay. What can I do to convince you otherwise? HTML_TEMPLATE_IT is >> veeery similar to what's already happening, but with two benefits - a >> standardized way of doing the template code, and simpler "loop" support, >> which currently is done in a bunch of different ways, including >> having the >> html included in the php code which lessens the usefulness of the >> template. If I rewrote draw_day/day.tmpl to show you the difference (and >> gave you some performance numbers, which should be roughly the same or >> maybe even better)? >> >> >>> We're not really interested in a templating add-on that would require >>> PEAR or Smarty. Smarty is bloated and really overkill for the >>> project. Writing our own template engine presented a way to provide >>> the fastest method of displaying content and allowing users to tweak >>> the code with little php knowledge. >>> >>> -C >>> >>> >>> On May 21, 2005, at 11:12 AM, da...@d2... wrote: >>> >>> >>>>> David Fallon wrote: >>>>> >>>>> >>>>>> Ugh, the switch to not using forms openevent stuff was a can o' >>>>>> worms. >>>>>> This would be vastly easier if we used a real template system - >>>>>> is there >>>>>> a reason we're not using one of the template classes from PEAR? >>>>>> (http://pear.php.net/manual/en/package.html.php) I've used >>>>>> HTML_TEMPLATE_IT, and it works well and the syntax is almost >>>>>> identical >>>>>> (in the template) to what's already there. The code syntax is >>>>>> significantly different, of course, since all the "hard work" (the >>>>>> various regexes all over the place) is abstracted out for you. :) >>>>>> While >>>>>> I should learn my lesson after diving into this rewrite, I volunteer >>>>>> myself to do the switchover if I get approval. This, of course, is a >>>>>> fairly serious rewrite, but continues my "less code" mantra. >>>>>> >>>>>> >>>>> >>>>> Have you had a look at smarty.php.net? We used to use >>>>> HTML_TEMPLATE_IT >>>>> but smarty has some neat features such as caching that make things >>>>> faster and other nifty features that make templating easier >>>>> >>>>> >>>> >>>> I haven't looked at it much, but I will take a closer look. In my >>>> brief 5 >>>> sec. glance after your email, two concerns jumped out - the syntax is >>>> decently different than the existing template stuff in phpicalendar >>>> (while >>>> html_template_it is almost identical), and it's not integrated into >>>> php/pear, meaning we'd have to have an additional install >>>> requirement. The >>>> second one being the bigger of the two, since I'd definitely recommend >>>> staying away from any additional install requirements. >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by Oracle Space Sweepstakes >>>> Want to be the first software developer in space? >>>> Enter now for the Oracle Space Sweepstakes! >>>> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >>>> _______________________________________________ >>>> Phpicalendar-devel mailing list >>>> Php...@li... >>>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >>>> >>>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by Oracle Space Sweepstakes >>> Want to be the first software developer in space? >>> Enter now for the Oracle Space Sweepstakes! >>> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >>> _______________________________________________ >>> Phpicalendar-devel mailing list >>> Php...@li... >>> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >>> >>> >>> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by Oracle Space Sweepstakes >> Want to be the first software developer in space? >> Enter now for the Oracle Space Sweepstakes! >> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >> _______________________________________________ >> Phpicalendar-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel > |
×
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