Menu
▾
▴
phpicalendar-devel
|
From: Greg W. <gr...@gr...> - 2002-11-22 20:22:12
|
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 |
|
From: Alex E. <ta...@sp...> - 2002-11-22 22:47:56
|
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 |
|
From: Patrick B. <pb...@pi...> - 2002-11-23 00:35:57
|
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= |
|
From: Ed <co...@fu...> - 2002-11-23 03:11:23
|
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 |
|
From: Greg W. <gr...@gr...> - 2002-11-23 15:36:49
|
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 > |
|
From: Ed F. <co...@fu...> - 2002-11-23 16:46:09
|
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 |
|
From: Chad <ch...@ch...> - 2002-11-23 18:20:21
|
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 |
|
From: Ed F. <co...@fu...> - 2002-11-23 18:54:25
|
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 |
|
From: Chad <ch...@ch...> - 2002-11-23 22:17:39
|
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 |
|
From: Ed F. <co...@fu...> - 2002-11-23 23:25:40
|
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 |
|
From: Greg W. <gr...@gr...> - 2002-11-23 15:12:43
|
> 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 |
|
From: Jared <xe...@si...> - 2002-11-22 23:05:33
|
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 |
|
From: Chad <ch...@ch...> - 2002-11-22 23:25:06
|
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 |
|
From: Ed <co...@fu...> - 2002-11-23 02:37:22
|
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 |
×
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