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

[Chad <ch...@ch...>]

It is separate, a parser and a viewer. The viewer, however, is just as 
complex as the parser. At least for me it is heh. The viewer still 
needs to look and properly act like a calendar, plus support 
overlapping functions. Print view is a good example of using the parser 
to display whatever you like it to. So don't say I didnt warn yah. ;)


On Saturday, November 23, 2002, at 10:58  AM, Ed Finkler wrote:
>
> 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
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel