Re: [PHPiCalendar-DEV] Re: XHTML and "big" features

[Ed F. <co...@fu...>]

Chad wrote:
> Hi all -
> I've never understood how a template system would work this since its a  
> calendar. The php code draws the calendar. You can work on it if you  
> like but its not going into the project until after 1.0. I don't want  
> to make these kinds of big changes until the calendar parser and  
> underlying code is running 100% or better, and quite frankly it is not.

But based on what you said here:

http://phpicalendar.sourceforge.net/phpBB2/viewtopic.php?t=120

The parser and underlying code are already separated decently from the 
presentation.  I don't see how changing the presentation stuff further 
-- without altering the hooks to the parser -- has an impact on the parser.

> Secondly, I've seen zero evidence of people wanting templates. A  
> templating system is merely a solution looking for a problem. We've  
> provided a means to fairly easily allow 'regular guys' to change the  
> look of their calendars with headers, footers, and style sheets. Yet  
> 99% of the installations take use of the provided themes. Noone has  
> even submitted their theme back to us!

Well, I already expressed my interest in it at the forum link above. 
Your responses there implied that you were at least open to the template 
concept.  That's why I've pursued it.

As for it being "a solution looking for a problem," I think that's 
inaccurrate.  Templates allow for much more flexibility in terms of 
presentation, and while many people don't pursue it (because the 
majority of your users just want a plug-in solution), I know that if 
you're trying to intergrate an app like this into a larger framework, 
having a template system will make the job easier.  Sure, a lot of 
people won't use it, but if someone (like me) is volunteering their time 
to do it, and it won't detrimentally impact the rest of the app, I'm not 
sure I see the downside.

> Our way is easy, I've looked at smarty and how projects like PHPBB do  
> themes and it loses me. True there can be even more separation of code  
> and display, which is what we should be looking at.

Which is what I'm trying to do -- have stronger separation of logic and 
presentation.  And I have a fair bit of familiarity with template 
systems, so I thought this would be a good way for me to contribute.

> XHTML: I guess I'm missing what the point is. The only reason to recode  
> the entire project would have to be that there is a great benefit from  
> what XHTML offers. Noone has pointed out what that was or why we should  
> switch. Is ditching 4.0 Browser users worth it? Apple still ships  
> Netscape 4.7 on every single Mac today.

XHTML handles fine in NS4, with a little bit care with the syntax.  And 
I believe I brought up the benefits (at least that I see) of XHTML in a 
previous email -- they are the same benefits you derive from using any 
XML-based schema.

> http://phpicalendar.sourceforge.net/nuke/ 
> modules.php?name=Surveys&op=results&pollID=4&mode=&order=&thold=
> 
> These are the things our users want. Multi-User support, Multi-Calendar  
> Support, Optional SQL support, and editing calendars.
>
> The parser is slow. Needs to be faster. Needs to be a program. It  
> should morph into a global class.
> $phpical->getdate(20021123);
> $phpical->gettodos
> 
> Although the above is something Jared and I have been talking about. If  
> something like that existed, templates and everything else would be  
> much simpler.

I can't speak as well to the other features, but I can tell you that 
moving to a class rather than function-based approach will have little 
impact on the ease of intergrating a template system.  Whether you get 
the data from a method call or a function call, you still collect the 
data and render the template.

Not that I object to moving to a class -- it encourages modular coding, 
which I'm all for.

> Ok, so I've rambled on a bit. I've needed to point out my views on many  
> of the emails floating around here. Seems like every so often a big  
> swell of interest comes and thats very very good. I just would like us  
> more focused on getting to 1.0 before trying to re-invent the calendar.  

That's cool.  When you said in a previous email "Personally I'd like to 
pack as many features in 0.9 as possible," I thought that indicated 
interest in features like this.

Let me make myself clear: I am *not* in any way talking about 
restructuring the current layout of the app.  All the filenames will be 
the same, and all the files will continue to do the same basic thing. 
The only different will be that instead of files like "month.php" 
producing the markup themselves, they will make calls to a template 
system.  Nothing related to the parsing and data extraction routines 
will change.

> I think most of you will agree. I am still interested in seeing  
> examples.

Well, that was my plan, so I guess I'll continue with it. 8)

-- 
"it's like an addiction to idiocy" -j
-Ed