phpicalendar-devel — Mailing list for PHP iCalendar Developers

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

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

Chad wrote:
> 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. ;)

Oh yeah, I know the display code is complex -- all calendar displays 
are.  I'm not saying it's a piece of cake, but it's not too terribly 
difficult.

Like I said, I'll throw together an example to see.  If it seems kosher, 
I'll continue working on it.

Now I just need to find time to do it... 8)

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

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

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

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

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

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.

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!

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.

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.

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.

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.  
I think most of you will agree. I am still interested in seeing  
examples. Of course Jared's opinion counts as much as mine does, its a  
good bit his project too.

Cheers,
C


On Saturday, November 23, 2002, at 08:49  AM, Ed Finkler wrote:

> Greg Westin wrote:
>> The problem, as I see it, is to make sure that we're not JUST writing
>> perfect XHTML.  In other words, if we're really concerned about
>> compatibility, we should be checking sites with something like Bobby  
>> to
>> figure out potential problems.
>
> Not a bad idea.  In the very least, people should be using the w3c  
> validators more.
>
>> The only problem I've ever had with XHTML is that Mozilla/5 (Netscape  
>> 6?)
>> has a bug in it.  When it encounters a DOCTYPE declaration,  
>> positioning on
>> the page can get messed up.  Luckily, this doesn't happen with earlier
>> browsers, later versions of Netscape, or any other browsers I've  
>> found, so
>> you can simply check for the browser and only deliver the DOCTYPE
>> declaration if it doesn't have Mozilla/5 as it's user agent. (Or  
>> Gecko, I
>> think).
>
> Interesting... I've never run into this, and I run Mozilla (or its  
> variants) pretty exclusively.
>
> To bring this back to PHPiCalendar:
>
> Personally, as I've said before, I think we should implement a  
> templating system that removes markup entirely from the PHP code.  I  
> didn't get much response from my early request for recommendations on  
> which template class to use, so I'll do the following:
>
> 1) get the current CVS
> 2) pick a templating system
> 3) integrate the templating system into one page as a "proof of  
> concept"
> 4) Let everybody take a look at it
>
> If no one raises an objection, I'll try to work on that tonight or  
> tomorrow.
>
> -- 
> "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

Re: XHTML and "big" features was Re: [PHPiCalendar-DEV] $_GET variables

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

Greg Westin wrote:
> The problem, as I see it, is to make sure that we're not JUST writing
> perfect XHTML.  In other words, if we're really concerned about
> compatibility, we should be checking sites with something like Bobby to
> figure out potential problems.

Not a bad idea.  In the very least, people should be using the w3c 
validators more.

> The only problem I've ever had with XHTML is that Mozilla/5 (Netscape 6?)
> has a bug in it.  When it encounters a DOCTYPE declaration, positioning on
> the page can get messed up.  Luckily, this doesn't happen with earlier
> browsers, later versions of Netscape, or any other browsers I've found, so
> you can simply check for the browser and only deliver the DOCTYPE
> declaration if it doesn't have Mozilla/5 as it's user agent. (Or Gecko, I
> think).

Interesting... I've never run into this, and I run Mozilla (or its 
variants) pretty exclusively.

To bring this back to PHPiCalendar:

Personally, as I've said before, I think we should implement a 
templating system that removes markup entirely from the PHP code.  I 
didn't get much response from my early request for recommendations on 
which template class to use, so I'll do the following:

1) get the current CVS
2) pick a templating system
3) integrate the templating system into one page as a "proof of concept"
4) Let everybody take a look at it

If no one raises an objection, I'll try to work on that tonight or tomorrow.

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

Re: XHTML and "big" features was Re: [PHPiCalendar-DEV] $_GET variables

[Greg W. <gr...@gr...>]

The problem, as I see it, is to make sure that we're not JUST writing
perfect XHTML.  In other words, if we're really concerned about
compatibility, we should be checking sites with something like Bobby to
figure out potential problems.

The only problem I've ever had with XHTML is that Mozilla/5 (Netscape 6?)
has a bug in it.  When it encounters a DOCTYPE declaration, positioning on
the page can get messed up.  Luckily, this doesn't happen with earlier
browsers, later versions of Netscape, or any other browsers I've found, so
you can simply check for the browser and only deliver the DOCTYPE
declaration if it doesn't have Mozilla/5 as it's user agent. (Or Gecko, I
think).

More comments on this are certainly welcome, though.  I haven't heard much
opposition to XHTML on compatibility grounds lately.

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

On Fri, 22 Nov 2002, Ed wrote:

>
> On Friday, November 22, 2002, at 07:35  PM, Patrick Berry wrote:
> > Before we go down this road, you might want to take a peek at:
> >
> > Sending XHTML as text/html Considered Harmful
> > http://www.hixie.ch/advocacy/xhtml
>
> I've read this before, and I think the guy is strongly overstating the
> point.  This might have been accurate 2 years ago, but nowadays it's
> very hard to run across a user agent that doesn't handle XHTML1.0
> Transitional properly.  He's not wrong, per se... I think his points
> are just not relevant in the vast majority of cases.  Much of his
> argument boils down to support of legacy and non-pc user agents, which
> is ironic since XHTML's XML nature in fact allows you to more elegantly
> solve that problem than HTML4.01 can.
>
> I've recently redone a major InfoSec site in XHTML and CSS, and have
> yet to run into any of the problems he mentions, despite the fact that
> I'm supporting browsers as old as NS4.
>
> > A Warning to Others
> > http://diveintomark.org/archives/2002/11/21.html#a_warning_to_others
> > Someday, I=92ll upgrade myself from =93SHOULD NOT chase after bleeding
> > edge technologies that don=92t solve real world problems=94 to =93MUST =
NOT
> > chase after bleeding edge technologies that don=92t solve real world
> > problems=94.
>
> The big reason to use XHTML is its XML nature... not (imho) because of
> anything the language adds over HTML.  Those XML-inherent properties
> that intersted me the most included the cleaner syntax and the ability
> to transform between schema.  Those definitely *do* solve real world
> problems.  If they're not issues for you, though, it's certainly going
> to be of less use.
>
> > One of the things that immediately attracted my to phpiCalendar was
> > the 'drop it in, and it works' installation.  There has been lots of
> > talk of grander features, and I'm wondering if a potential fork of the
> > code would be prudent to make sure they ease of install is always
> > there.  If all the easy can be contained in the prefs, there should be
> > no need to fork off into a "lite" version.  A fork would be a pain for
> > many, many reasons, I know.  Just tossing stuff out...imagine putting
> > in support for Smarty templates or databases.
>
> I don't think the additional features should hurt the ease of install
> as long as the default settings don't enable things that require more
> work (like database setup).  For example, phpBB2 includes a very
> full-featured template/theme system, but it's clear that the majority
> of installers don't make any use of it.  I'm definitely glad it's
> there, though.
>
> I've done some experiments with replacing the embedded markup that
> currently exists in PHPiCalendar with an existing templating system,
> and it went pretty well.  Templating would also be a good way to make
> everyone happier regarding HTML vs XHTML -- you can just role your own
> templates without interfering with the main codebase.
>
> --
> "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
>

Re: [PHPiCalendar-DEV] $_GET variables

[Greg W. <gr...@gr...>]

> To that end, is there any idea of how much of the code generated by
> phpiCalendar is XHTML-compliant. I haven't done a thorough enough look see
> at the HTML bits to have an idea. I would like to see this project move
> toward 100% XHTML compatibility, if possible. Of course, this being the
> developer list, I offer my services in accomplishing either of the above
> suggestions.

I agree... I'm a big fan of XHTML.  I make a point of writing
XHTML-compliant code whenever I'm writing HTML, and would be glad to help
pore over the code to find any lurking incompatibilities.

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

Re: [PHPiCalendar-DEV] Developer interest

[Jon C. T. <cal...@wa...>]

Hi, folks.  Thanks so much for PHP iCalendar.  It got my organization 
out of a long stale relationship with WebEvent 3.5.  :)  The new 
iCal-powered site is a big hit with our users.

I've been doing some work on displaying multiple calendars at once.  I 
did an initial bad implementation for calendar.wap.org, and now I'm 
going back and taking a clean approach.  I'd be flattered if it's 
considered suitable for checkin.

I've broken down my plan into stages, and posted a description online.  
Along with an up-to-date CVS diff implementing the first stage.

     <http://calendar.wap.org/patches.html>

I guess I'll keep going unless somebody tells me to stop.  :)  I'd 
welcome any guidance you can offer.  Thanks!

On Friday, November 22, 2002, at 01:45  AM, Chad wrote:
>
> Personally I'd like to pack as many features in 0.9 as possible, as 
> we'll need people to really test out before 1.0. Ive already done many 
> of these in CVS. Check the README file for changes. I'd also like to 
> add more permanent developers to the SourceForge list. Submit us some 
> nices patches and win us over.You'll need to butter both Jared and 
> myself up those.

[PHPiCalendar-DEV] CVS locked?

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

Anyone have any ideas? I get this when checking in tonight:

cvs server: [23:19:10] waiting for catalyst_0's lock in 
/cvsroot/phpicalendar/phpicalendar


-C

Re: XHTML and "big" features was Re: [PHPiCalendar-DEV] $_GET variables

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

On Friday, November 22, 2002, at 07:35  PM, Patrick Berry wrote:
> Before we go down this road, you might want to take a peek at:
>
> Sending XHTML as text/html Considered Harmful
> http://www.hixie.ch/advocacy/xhtml

I've read this before, and I think the guy is strongly overstating the=20=

point.  This might have been accurate 2 years ago, but nowadays it's=20
very hard to run across a user agent that doesn't handle XHTML1.0=20
Transitional properly.  He's not wrong, per se... I think his points=20
are just not relevant in the vast majority of cases.  Much of his=20
argument boils down to support of legacy and non-pc user agents, which=20=

is ironic since XHTML's XML nature in fact allows you to more elegantly=20=

solve that problem than HTML4.01 can.

I've recently redone a major InfoSec site in XHTML and CSS, and have=20
yet to run into any of the problems he mentions, despite the fact that=20=

I'm supporting browsers as old as NS4.

> A Warning to Others
> http://diveintomark.org/archives/2002/11/21.html#a_warning_to_others
> Someday, I=92ll upgrade myself from =93SHOULD NOT chase after bleeding=20=

> edge technologies that don=92t solve real world problems=94 to =93MUST =
NOT=20
> chase after bleeding edge technologies that don=92t solve real world=20=

> problems=94.

The big reason to use XHTML is its XML nature... not (imho) because of=20=

anything the language adds over HTML.  Those XML-inherent properties=20
that intersted me the most included the cleaner syntax and the ability=20=

to transform between schema.  Those definitely *do* solve real world=20
problems.  If they're not issues for you, though, it's certainly going=20=

to be of less use.

> One of the things that immediately attracted my to phpiCalendar was=20
> the 'drop it in, and it works' installation.  There has been lots of=20=

> talk of grander features, and I'm wondering if a potential fork of the=20=

> code would be prudent to make sure they ease of install is always=20
> there.  If all the easy can be contained in the prefs, there should be=20=

> no need to fork off into a "lite" version.  A fork would be a pain for=20=

> many, many reasons, I know.  Just tossing stuff out...imagine putting=20=

> in support for Smarty templates or databases.

I don't think the additional features should hurt the ease of install=20
as long as the default settings don't enable things that require more=20
work (like database setup).  For example, phpBB2 includes a very=20
full-featured template/theme system, but it's clear that the majority=20
of installers don't make any use of it.  I'm definitely glad it's=20
there, though.

I've done some experiments with replacing the embedded markup that=20
currently exists in PHPiCalendar with an existing templating system,=20
and it went pretty well.  Templating would also be a good way to make=20
everyone happier regarding HTML vs XHTML -- you can just role your own=20=

templates without interfering with the main codebase.

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

Re: [PHPiCalendar-DEV] $_GET variables

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

On Friday, November 22, 2002, at 06:21  PM, Chad wrote:

> Well we've had a number of bugs submitted on pre 4.1 installs in the 
> past. The problem is many users have no control over what there server 
> admins put on the system, and getting them to upgrade may not be 
> possible. I think about two things:
>
> 1) Its extra work to change, not much but it is.
> 2) It decreases our possible install base.
>
> By contrast Squirrelmail just now started requiring 4.0.6 from 4.0.2. 
> I think our current level is fine for the moment. I'm sure we'll raise 
> it in the future.

I can see your point.  I think as long as we're maintaining proper 
security practices by not relying on register_globals, using the old 
global arrays is okay.  I doubt the $HTTP_* arrays will go away anytime 
soon, and if they do, it's simple enough to do a search and replace on 
them.

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

[PHPiCalendar-DEV] index.php patch (select correct calendar from url)

[blaine <la...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's a quick patch that allows a url to be constructed as follows:

index.php?cal=Calendar

- --- BEGIN DIFF

Index: index.php
===================================================================
RCS file: /cvsroot/phpicalendar/phpicalendar/index.php,v
retrieving revision 1.5
diff -u -r1.5 index.php
- --- index.php   17 Nov 2002 02:32:10 -0000      1.5
+++ index.php   23 Nov 2002 02:33:02 -0000
@@ -5,11 +5,18 @@
         $phpicalendar           = 
unserialize(stripslashes($HTTP_COOKIE_VARS['phpicalendar']));
         $default_view           = $phpicalendar['cookie_view'];
  }
+
  if ($printview_default == 'yes') {
         $default_view = "print.php?printview=$default_view";
  } else {
         $default_view = "$default_view" . ".php";
  }
+
+if (isset($HTTP_GET_VARS['cal'])) {
+    $cal = $HTTP_GET_VARS['cal'];
+    $default_view .= "?cal=$cal";
+}
+
  header("Location: $default_view");

- -?>
\ No newline at end of file
+?>

- --- END DIFF

I wanted to be able to create RSS links that automatically went to the 
appropriate calendar, without bypassing the default calendar view. The 
above patch fixes that, and this diff fixes the RSS generator:

- --- BEGIN DIFF

Index: rss.php
===================================================================
RCS file: /cvsroot/phpicalendar/phpicalendar/rss/rss.php,v
retrieving revision 1.15
diff -u -r1.15 rss.php
- --- rss.php     22 Nov 2002 21:16:58 -0000      1.15
+++ rss.php     23 Nov 2002 02:35:02 -0000
@@ -43,7 +75,7 @@
  $rss .= '<rss version="0.91">'."\n";
  $rss .= '<channel>'."\n";
  $rss .= '<title>'.$cal_displayname.' - '.$theview.'</title>'."\n";
- -$rss .= '<link>'.htmlspecialchars ("$default_path").'</link>'."\n";
+$rss .= '<link>'.htmlspecialchars 
("$default_path").'/index.php?cal='.$cal_displayname.'</link>'."\n";
  $rss .= '<description>'.$cal_displayname.' '.$calendar_lang.' - 
'.$theview.'</description>'."\n";
  $rss .= '<language>'.$rss_language.'</language>'."\n";
  $rss .= '<copyright>Copyright 2002, '.htmlspecialchars 
("$default_path").'</copyright>'."\n";

- --- END DIFF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE93unP0LjU31/N6YgRAkVBAKClEN8uKgO5gB4BnGpxvDXaEviXaACdG53O
BiPP+I3RHHGfvOU5e2cXi5U=
=vZcX
-----END PGP SIGNATURE-----

[PHPiCalendar-DEV] More-dynamic RSS patch

[blaine <la...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I've written up a patch for PHP iCalendar's RSS feeds that resolves 
feature request #642560 (posted by me). Basically, this patch allows 
you to specify the rssview as 'list', and get the next x events over 
the next y days.

The patch is available at: 
http://resist.ca/~lattice/phpical-rss-list.patch.gz

If you'd like to see an example of how this feed works, go to: 
http://calendar.resist.ca/rss/

I hope this scratches an itch for someone other than myself! :-)

blaine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE93tqY0LjU31/N6YgRAuCYAJwLP3odIudLXcuhZvGEafrhTSXUYgCeNClJ
UW4nwwceThyAwme4ED1JeII=
=q1UA
-----END PGP SIGNATURE-----

XHTML and "big" features was Re: [PHPiCalendar-DEV] $_GET variables

[Patrick B. <pb...@pi...>]

On Friday, November 22, 2002, at 02:47  PM, Alex Ezell wrote:

> To that end, is there any idea of how much of the code generated by=20
> phpiCalendar is XHTML-compliant. I haven't done a thorough enough look=20=

> see at the HTML bits to have an idea. I would like to see this project=20=

> move toward 100% XHTML compatibility, if possible. Of course, this=20
> being the developer list, I offer my services in accomplishing either=20=

> of the above suggestions.


Before we go down this road, you might want to take a peek at:

Sending XHTML as text/html Considered Harmful
http://www.hixie.ch/advocacy/xhtml

and also:

A Warning to Others
http://diveintomark.org/archives/2002/11/21.html#a_warning_to_others
Someday, I=92ll upgrade myself from =93SHOULD NOT chase after bleeding =
edge=20
technologies that don=92t solve real world problems=94 to =93MUST NOT =
chase=20
after bleeding edge technologies that don=92t solve real world =
problems=94.


One of the things that immediately attracted my to phpiCalendar was the=20=

'drop it in, and it works' installation.  There has been lots of talk=20
of grander features, and I'm wondering if a potential fork of the code=20=

would be prudent to make sure they ease of install is always there.  If=20=

all the easy can be contained in the prefs, there should be no need to=20=

fork off into a "lite" version.  A fork would be a pain for many, many=20=

reasons, I know.  Just tossing stuff out...imagine putting in support=20
for Smarty templates or databases.

Pat=

Re: [PHPiCalendar-DEV] Multi-User code

[Alex E. <ta...@sp...>]

On Fri, 22 Nov 2002 16:31:53 -0700 (MST), Cory B. <pi...@hi...> wrote:

> Alex,
>
> I'de be happy take a look at the code... Feel free to email it to me or
> give a web link to where I can download it.
>
> Thanks,
>
> -Cory

Here's a URL where everyone can get a Zip with the code:

http://taranis.spittingllamas.com/multiuser/phpicalendar-0.8.1- 
multiuser.rar

It only includes the files that changed from the 0.8.1 release.

Don't have time to document much right now, but I will answer some 
questions on Monday. The only thing I can say is that I need to work on the 
session management some more. I already have some ideas about how to do 
that.

Enjoy.

-- 
Alex Ezell
http://www.spittingllamas.com
"Formal Restrictions, contrary to what you might think, free you up by allowing 
  you to concentrate on purer ideas."
- Winter Sorbeck in Chip Kidd's The Cheese Monkeys

Re: [PHPiCalendar-DEV] Multi-User code

[Cory B. <pi...@hi...>]

Alex,

I'de be happy take a look at the code... Feel free to email it to me or
give a web link to where I can download it.

Thanks,

-Cory


> I have some multi-user code running nicely on the 0.8.1 release.
>
> The only problem I have now is that it is written specifically for my
> situation. In other words, it uses things like REMOTE_USER because I
> have  the calendar system behind some basic Apache security. It also
> uses  sessions to track the logged in user and which user's calendar
> should be  shown. I want to refine the sessions work. In writing this
> message, I had a  thought about how something should be done. So, some
> of those solutions  wouldn't be as universal as a true multi-user system
> maybe should be.
>
> I'm not sure this should be mixed into the CVS. In fact, I'm 90% certain
> it  shouldn't be, but I thought that some of you might be interested. I
> can  post the code to my website Monday (not publicly!) for you all to
> download.  Or I can email it to those of you who ask.
>
> Some thanks now, since this is my first message to the group. Thanks to
> the  dev team for giving us some great code to work with. And thanks
> also to  Jamie (curmi) for his original multi-user code. Thanks to Greg
> Westin for  his excellent tutorials on his site.
>
> --
> Alex Ezell
> http://www.spittingllamas.com
> "Formal Restrictions, contrary to what you might think, free you up by
> allowing  you to concentrate on purer ideas."
> - Winter Sorbeck in Chip Kidd's The Cheese Monkeys
>
>
> -------------------------------------------------------
> 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

Re: [PHPiCalendar-DEV] $_GET variables

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

Well we've had a number of bugs submitted on pre 4.1 installs in the 
past. The problem is many users have no control over what there server 
admins put on the system, and getting them to upgrade may not be 
possible. I think about two things:

1) Its extra work to change, not much but it is.
2) It decreases our possible install base.

By contrast Squirrelmail just now started requiring 4.0.6 from 4.0.2. I 
think our current level is fine for the moment. I'm sure we'll raise it 
in the future.

-C

On Friday, November 22, 2002, at 03:05  PM, Jared wrote:

> On Friday, November 22, 2002, at 02:22  PM, Greg Westin wrote:
>
>> Let me know if there's something wrong with making this change, or a
>> reason $HTTP_GET_VARS was chosen over $_GET.  Otherwise, I can go 
>> through
>> and change it in all the files and submit the diffs.
>>
>> Greg
>
> Well, I prefer $_GET as well, but we specifically chose $HTTP_GET_VARS 
> to provide as much backwards compatibility as we can. As of now, all 
> versions of PHP still handle $HTTP_GET_VARS and PHP iCalendar will run 
> on 4.0.3 or higher (I believe that's as far back as we go). We don't 
> use it all that often and a simple find/replace will update PHP 
> iCalendar when a version of PHP is released that no longer supports 
> $HTTP_GET_VARS.
>
> If everyone is willing to put a higher PHP version limit on PHP 
> iCalendar, I am willing to go with $_GET. It's what I use on my 
> personal projects, anyway, so it'll just make things nicer. There are 
> some things that would get easier if we went with a higher 
> requirement. Maybe we should just say 4.1?
>
> -Jared
>
>
>
>
> -------------------------------------------------------
> 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

Re: [PHPiCalendar-DEV] $_GET variables

[Jared <xe...@si...>]

On Friday, November 22, 2002, at 02:22  PM, Greg Westin wrote:

> Let me know if there's something wrong with making this change, or a
> reason $HTTP_GET_VARS was chosen over $_GET.  Otherwise, I can go 
> through
> and change it in all the files and submit the diffs.
>
> Greg

Well, I prefer $_GET as well, but we specifically chose $HTTP_GET_VARS 
to provide as much backwards compatibility as we can. As of now, all 
versions of PHP still handle $HTTP_GET_VARS and PHP iCalendar will run 
on 4.0.3 or higher (I believe that's as far back as we go). We don't 
use it all that often and a simple find/replace will update PHP 
iCalendar when a version of PHP is released that no longer supports 
$HTTP_GET_VARS.

If everyone is willing to put a higher PHP version limit on PHP 
iCalendar, I am willing to go with $_GET. It's what I use on my 
personal projects, anyway, so it'll just make things nicer. There are 
some things that would get easier if we went with a higher requirement. 
Maybe we should just say 4.1?

-Jared

Re: [PHPiCalendar-DEV] $_GET variables

[Alex E. <ta...@sp...>]

On Fri, 22 Nov 2002 15:22:20 -0500 (EST), Greg Westin <gr...@gr...> wrote:

> I think it would be a better idea to use $_GET, unless there's a
> reason not to.  $HTTP_GET_VARS is deprecated, and is not autoglobal like
> $_GET.

I can second this motion. It would be especially nice in working towards 
0.9 to have code that is in line with the "best practices" if not totally 
in line with standards.

To that end, is there any idea of how much of the code generated by 
phpiCalendar is XHTML-compliant. I haven't done a thorough enough look see 
at the HTML bits to have an idea. I would like to see this project move 
toward 100% XHTML compatibility, if possible. Of course, this being the 
developer list, I offer my services in accomplishing either of the above 
suggestions.

Thanks.

-- 
Alex Ezell
http://www.spittingllamas.com
"Formal Restrictions, contrary to what you might think, free you up by allowing 
  you to concentrate on purer ideas."
- Winter Sorbeck in Chip Kidd's The Cheese Monkeys

[PHPiCalendar-DEV] Multi-User code

[Alex E. <ta...@sp...>]

I have some multi-user code running nicely on the 0.8.1 release.

The only problem I have now is that it is written specifically for my 
situation. In other words, it uses things like REMOTE_USER because I have 
the calendar system behind some basic Apache security. It also uses 
sessions to track the logged in user and which user's calendar should be 
shown. I want to refine the sessions work. In writing this message, I had a 
thought about how something should be done. So, some of those solutions 
wouldn't be as universal as a true multi-user system maybe should be.

I'm not sure this should be mixed into the CVS. In fact, I'm 90% certain it 
shouldn't be, but I thought that some of you might be interested. I can 
post the code to my website Monday (not publicly!) for you all to download. 
Or I can email it to those of you who ask.

Some thanks now, since this is my first message to the group. Thanks to the 
dev team for giving us some great code to work with. And thanks also to 
Jamie (curmi) for his original multi-user code. Thanks to Greg Westin for 
his excellent tutorials on his site.

-- 
Alex Ezell
http://www.spittingllamas.com
"Formal Restrictions, contrary to what you might think, free you up by 
allowing  you to concentrate on purer ideas."
- Winter Sorbeck in Chip Kidd's The Cheese Monkeys

[PHPiCalendar-DEV] todo.php

[Greg W. <gr...@gr...>]

OK, so I have a preliminary todo.php and functions/todo.js going, and I
modified the TODO section if functions/ical_parser.php to use variables
like todo_text rather than event_text.  Also, I've updated sidebar.php to
call the new Javascript function, and day.php, week.php, and month.php to
include functions/todo.js.

How should I go about submitting this and future code?  Should I just
throw up a whole bunch of diffs in a comment on the sourceforge page?

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

[PHPiCalendar-DEV] $_GET variables

[Greg W. <gr...@gr...>]

In opening the events.php file to get an idea of how to create a similar
one for to-dos, I noticed that PHP iCalendar uses $HTTP_GET_VARS.  In
general, I think it would be a better idea to use $_GET, unless there's a
reason not to.  $HTTP_GET_VARS is deprecated, and is not autoglobal like
$_GET.

Let me know if there's something wrong with making this change, or a
reason $HTTP_GET_VARS was chosen over $_GET.  Otherwise, I can go through
and change it in all the files and submit the diffs.

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

Re: [PHPiCalendar-DEV] VTODO sorting

[Greg W. <gr...@gr...>]

Dear Chad and other VTODO-concerned people,

> It would seem that Low Priority is more important than No Priority and
> should sort No priority to the very bottom.

I think that's a shame, because I wish there were a way for me to indicate
that certain events are unimportant, meaning they should go to the bottom
of the heap, in addition to being able to push events to the top.  As it
stands, at least in the iCal implementation, I have to give every to-do a
priority if I want certain ones at the bottom.  I suppose this would be
solved if iCal gave every event some sort of medial priority by default,
and let you choose to either raise or lower that, but... alas.

> I haven't gotten it that far yet, not sure when you last checked cvs,
> as there is basic sorting of events. I cheat a bit and give no priority
> events a "10" and completed events and "11" for sanity sorting sake. I
> also havent figured out what to do if there is no due date, for sorting
> sake I was just putting it one year after the start date.

I think you could get around this hack if you used usort().  That way, you
could specify in the comparison function how events without priority,
events without due dates, and completed events should be treated.  I think
you're right, though, in putting events with no due dates later than those
with, and events with no priority after those with priority, but before
completed events.

> What would be nice to have (if you want to work on it) is a todo.php
> for the java popup. Since the information is different the popup should
> contain more information such as submitted time, due date, priority,
> and other things found in the spec not supported in iCal.

I'll work on it.  I'd noticed that the pop-up was basically useless for
to-dos.

Rock on,

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

Re: [PHPiCalendar-DEV] VTODO sorting

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

 From the spec I have gathered this:

Priority 1-4 = High
Priority 5 = Medium
Priority 6-9 = Low
Priority 0 or no Priority = No Priority.

It would seem that Low Priority is more important than No Priority and 
should sort No priority to the very bottom.

This is what I was working towards implementing before I was 
sidetracked by a nasty bug, hehe. I have since stopped working on that 
bug and have turned all my findings over to David, who will look into 
it a bit this weekend if he has time (thanks!).

so i imagine the array would look something like:
	$master_array['-2']['priority']['due_date']

right now it looks like this:
	$master_array['-2']['priority']['uid']

I haven't gotten it that far yet, not sure when you last checked cvs, 
as there is basic sorting of events. I cheat a bit and give no priority 
events a "10" and completed events and "11" for sanity sorting sake. I 
also havent figured out what to do if there is no due date, for sorting 
sake I was just putting it one year after the start date.

What would be nice to have (if you want to work on it) is a todo.php 
for the java popup. Since the information is different the popup should 
contain more information such as submitted time, due date, priority, 
and other things found in the spec not supported in iCal.


Just my thoughts.
-C


On Friday, November 22, 2002, at 10:42  AM, Greg Westin wrote:

> I just started thinking about sorting the todos, so that high priority
> todos show up at the top (and maybe those with pressing due dates), but
> am not sure how best to go about it.
>
> I figure that they should be sorted first by priority, but I tend to 
> think
> that low priority items should go below those without any priority (is
> this sort of thing discussed in the iCalendar standard somewhere?  
> Could
> someone point me in the right direction?).  I think just a basic sort
> would put those without values last.  I would then tend to sort things 
> by
> due date within any given priority level.  Does that seem reasonable?
>
> Also, I'm not sure about how this sort of sorting would be best
> accomplished, technically.  A sort() or ksort() wouldn't work, because 
> the
> sort happens many levels above the level of the things being compared. 
>  A
> comment on php.net suggested that usort() would be the best thing for 
> this
> purpose.  Looking at the usort() documentation, it actually looks like 
> it
> should be fairly easy to write a function that does this sort of
> nontrivial comparison.
>
> I just wanted to see if anyone had any thoughts on this before I just 
> went
> ahead with it.
>
> Greg
>
> ---
> gr...@gr...
> http://www.gregwestin.com/
> Contact info: http://www.gregwestin.com/contact.php
>
>
>
> -------------------------------------------------------
> 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

[PHPiCalendar-DEV] VTODO sorting

[Greg W. <gr...@gr...>]

I just started thinking about sorting the todos, so that high priority
todos show up at the top (and maybe those with pressing due dates), but
am not sure how best to go about it.

I figure that they should be sorted first by priority, but I tend to think
that low priority items should go below those without any priority (is
this sort of thing discussed in the iCalendar standard somewhere?  Could
someone point me in the right direction?).  I think just a basic sort
would put those without values last.  I would then tend to sort things by
due date within any given priority level.  Does that seem reasonable?

Also, I'm not sure about how this sort of sorting would be best
accomplished, technically.  A sort() or ksort() wouldn't work, because the
sort happens many levels above the level of the things being compared.  A
comment on php.net suggested that usort() would be the best thing for this
purpose.  Looking at the usort() documentation, it actually looks like it
should be fairly easy to write a function that does this sort of
nontrivial comparison.

I just wanted to see if anyone had any thoughts on this before I just went
ahead with it.

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php