Menu
▾
▴
fofredux-devel — Developers discussion, bug fixing, and coding of fofredux
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(92) |
Dec
(142) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(33) |
Feb
(65) |
Mar
(76) |
Apr
(172) |
May
(124) |
Jun
(45) |
Jul
(76) |
Aug
(78) |
Sep
(1) |
Oct
(20) |
Nov
(6) |
Dec
(2) |
| 2007 |
Jan
(12) |
Feb
(7) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Andrew T. (nilspace) <nil...@us...> - 2006-04-14 04:06:32
|
Hi team & users, I'm very pleased to announce the release of FoFRedux v0.3 (finally). I've attached the ChangeLog below. You may notice it is *quite* long. Well done on all of the feature improvements, bug fixes, etc. FoFRedux has gotten much nicer and rounded-out in many of the dusty corners. There is a tarball/snapshot available from the Project Site: http://fofredux.sf.net/snapshots/fofredux-REL-0_3.tar.gz There is also the tarball in the Project releases on the sourceforge site. As you may be aware, it is time to say goodbye to the old, blocky interface to FoFRedux. The next version will have a complete redo of the User Interface to bring it up to speed in usability, speed, and aesthetics. Furthermore, there will be some major code rewrites in the core of FoFRedux to deal with growing cruft and also make the UI change-over better. Please review Khaled's prototypes and speak up now on any ideas you may have. We will also be moving to Subversion - so we'll put out a quick tutorial or references for that soon as well. Thanks again for all your help. Andrew Major: Add RSS output of feed items Added the ability to "save" an item for later retrieval Better XHTML markup for CSS styling and DOM control Podcast/Vidcast enclosure support PostgreSQL support Item Tagging (folksonomy) Minor: Search term highlighted in feed items Edit and delete categories Install page rewrite/cleanup Change the delete feed dialog to be more specific Make the "(None)" link optional via the config.php All feed links described as (rss) Show rss-image Add flag to keep feed from updating Bugs Fixed: Setting the category when adding a feed actually sets the feed's category Paged item count wrong Summary counts at top of feeds.php incorrect Fatal error when trying to delete feed Podcast feed breaks duplicate item detection Save or unsave Search within new items Searching within one specific feed Category variable not set in sort links $view value lost in framed feed list RSS reader can't read from pages served from another port Feed unread link in left frame loads un-framed item view Using the "m" link in frames shows control panel Edit Feed form returns you to itself Too many new items causes crash Bad feeds slow down or kill the update Fix relative URLs Author/Name Not Recognized for Atom Feeds |
|
From: Andrew T. <ajt...@hi...> - 2006-04-12 16:50:59
|
get it while it's hot. -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Miles B. <mil...@gm...> - 2006-04-12 16:49:44
|
On 4/12/06, Andrew Turner (nilspace) <nil...@us...> wrote= : > I feel good about the release now and think we should go ahead and > bundle it up and SHIP! > > Let me know if anyone has any immediate issues, or gives the thumbs up to > v0.3 I think we are ready now for 0.3 to be released. -Miles |
|
From: Andrew T. (nilspace) <nil...@us...> - 2006-04-12 16:41:23
|
On 4/12/06, Kevin <ke...@dr...> wrote: > > In subversion, which I hope we are migrated to before the next release, > each tag is a complete copy of trunk. This will hopefully eliminate the > problem of mismatched file tags. Yes, I would like us to move to Subversion for 0.4+ > In general, I don't like the idea of moving tags. If you want to update = a > release candidate, then that is a new RC tag. RC2-0_3, etc. What you ar= e > doing with the RC tag should be accomplished with a branch. You're definitely right - I'm a bad dev/release tech. > Looks good, how much of this can be accomplished with test cases, do you > think? Anything that touches an init.php function, should be a candidate > for automatic testing. Yes, there should be functional tests (calling init.php) but we can also investigate something like Selenium, which is a testing/IDE for doing UI testing of website. Supposedly (though I haven't verified), there is a Firefox plugin which you can set to record your actions as you click through a site. Then save these as a "Test" and replay them later. The idea is, I want to click several buttons, then verify the value of some of the HTML tags (they exist, hold certain values, etc.) This will be especially important when we incorporate Ajax elements. > I've thought of the idea of encapsulating all parameters that make up an > item view into an object.(tags, feeds, categories, search term, flag, etc= ) > That way, functions like fof_get_items() would be passed one parameter > instead of 8. That said. It would be the item_view object's job to > marshall/unmarshall query parameters for links. The item_view object > would also represent a saveable search. Good idea, though we don't want to create a struct for parameter simplicity sake. But having an object that represents a "View" that can then be serialized for saved queries is an excellent idea. We'll do this as part of pulling apart init.php into the UI, controller, and db interface parts. > > > I feel good about the release now and think we should go ahead and > > bundle it up and SHIP! > > > > Let me know if anyone has any immediate issues, or gives the thumbs up = to > > v0.3 > > Yipee!! > I'll take that as a thumbs-up from Kevin. Andrew -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2006-04-12 15:34:55
|
> Well, I was still dealing w/ my annoying and unreproducable problem. > I'm willing to put forth that it's something weird in my system/setup > that I'm somehow not catching, if no one else sees that problem. > > I actually just caught a bug dealing w/ what files from Head were > moved up to 0.3 and not. Init.php had an update to how it parsed opml > files, but add.php wasn't migrated to the 0.3 tag as well which > handled these changes. Therefore, importing an OPML file would always > fail. This was a shortcoming on my part to mark which files should > move forward. What do we do in the future to mark files on HEAD that > need to be moved to a new RC? In subversion, which I hope we are migrated to before the next release,=20 each tag is a complete copy of trunk. This will hopefully eliminate the problem of mismatched file tags. In general, I don't like the idea of moving tags. If you want to update = a release candidate, then that is a new RC tag. RC2-0_3, etc. What you ar= e doing with the RC tag should be accomplished with a branch. > Here are the prescribed tests for future releases. > Install: > 1) Install new from scratch > 2) Upgrade System from previous version (at least previous, further > back is good too) > 3) Uninstall > > Setup > 1) Add single feed of type: RSS 0.92, RSS 1.0, RSS 2.0, Atom > 2) Add feed of html page that uses auto-discovery > 3) Add invalid feed (html page, non-existing page, etc.) and verify > error message > 4) Add categories > 5) Add feeds with selected categories > 6) Export OPML file - verify that url, name, categories are written > for all feed items > 7) Import OPML file (with and without categories) > > Panel: > 1) Edit a feed, change category, url, name, location, tags, > auto-update & verify these changes took effect > 2) Edit a category - verify change took effect > 3) Delete a category- make sure feeds of that category changed to "None= " > 4) Set options for number of feeds, server time offset, etc. > 5) Create and remove tags > > View (both full page and framed): > 1) Verify all buttons in menu work as expected: e.g. > 2) View new items - verify they are paged, in the correct order, only > unread items are shown > 3) View all items > 4) View category > 5) View individual feed > 6) Tag an item, remove the tag > 7) Save an item, view saved feeds, unsave item > 8) Mark an item as read, verify it doesn't show up in new > 9) View all items, and mark items as unread - verify they show up in "n= ew > items" > 10) View feeds by a tag > 11) Use "flag up to" to mark items as read > 12) Mark all items as read/unread > 13) Verify that all other links in a feed item work (name, category, > in-item links) > 14) view "Old to new" and "new to old" > > Other: > 1) Search from the panel - all feeds should be searched > 2) Search within a view, only feeds in that view should be searched > 3) "Previous" and "next" within a search stays within a search Looks good, how much of this can be accomplished with test cases, do you think? Anything that touches an init.php function, should be a candidate for automatic testing. > Ok - I think that covers things in a rough way. I've tested most of > these (as I wrote them), There were several bugs in passing the order > and paging through the various nav links. These have been fixed and > tagged to RC-0_3. In fact, the keeping of parameters from one view to > the next seems odd, as *all* possible parameters will show up even if > they don't have values. This should be addressed in the next version. I've thought of the idea of encapsulating all parameters that make up an item view into an object.(tags, feeds, categories, search term, flag, etc= ) That way, functions like fof_get_items() would be passed one parameter instead of 8. That said. It would be the item_view object's job to marshall/unmarshall query parameters for links. The item_view object would also represent a saveable search. > I feel good about the release now and think we should go ahead and > bundle it up and SHIP! > > Let me know if anyone has any immediate issues, or gives the thumbs up = to > v0.3 Yipee!! --=20 Kevin |
|
From: Andrew T. (nilspace) <nil...@us...> - 2006-04-12 12:03:44
|
Well, I was still dealing w/ my annoying and unreproducable problem. I'm willing to put forth that it's something weird in my system/setup that I'm somehow not catching, if no one else sees that problem. I actually just caught a bug dealing w/ what files from Head were moved up to 0.3 and not. Init.php had an update to how it parsed opml files, but add.php wasn't migrated to the 0.3 tag as well which handled these changes. Therefore, importing an OPML file would always fail. This was a shortcoming on my part to mark which files should move forward. What do we do in the future to mark files on HEAD that need to be moved to a new RC? Here are the prescribed tests for future releases. Install: 1) Install new from scratch 2) Upgrade System from previous version (at least previous, further back is good too) 3) Uninstall Setup 1) Add single feed of type: RSS 0.92, RSS 1.0, RSS 2.0, Atom 2) Add feed of html page that uses auto-discovery 3) Add invalid feed (html page, non-existing page, etc.) and verify error message 4) Add categories 5) Add feeds with selected categories 6) Export OPML file - verify that url, name, categories are written for all feed items 7) Import OPML file (with and without categories) Panel: 1) Edit a feed, change category, url, name, location, tags, auto-update & verify these changes took effect 2) Edit a category - verify change took effect 3) Delete a category- make sure feeds of that category changed to "None" 4) Set options for number of feeds, server time offset, etc. 5) Create and remove tags View (both full page and framed): 1) Verify all buttons in menu work as expected: e.g. 2) View new items - verify they are paged, in the correct order, only unread items are shown 3) View all items 4) View category 5) View individual feed 6) Tag an item, remove the tag 7) Save an item, view saved feeds, unsave item 8) Mark an item as read, verify it doesn't show up in new 9) View all items, and mark items as unread - verify they show up in "new i= tems" 10) View feeds by a tag 11) Use "flag up to" to mark items as read 12) Mark all items as read/unread 13) Verify that all other links in a feed item work (name, category, in-item links) 14) view "Old to new" and "new to old" Other: 1) Search from the panel - all feeds should be searched 2) Search within a view, only feeds in that view should be searched 3) "Previous" and "next" within a search stays within a search Ok - I think that covers things in a rough way. I've tested most of these (as I wrote them), There were several bugs in passing the order and paging through the various nav links. These have been fixed and tagged to RC-0_3. In fact, the keeping of parameters from one view to the next seems odd, as *all* possible parameters will show up even if they don't have values. This should be addressed in the next version. Anyways, there are some changes in the RC, mostly the nav links discussed above. I also moved in the highlighting search and OPML changes that needed to be there to fix the current RC0.3 and brought in the cool "yellow" feature. :) I feel good about the release now and think we should go ahead and bundle it up and SHIP! Let me know if anyone has any immediate issues, or gives the thumbs up to v= 0.3 Andrew On 4/11/06, Kevin <ke...@dr...> wrote: > > > On 4/11/06, Kevin <ke...@dr...> wrote: > >> This is corrected in RC-0_3. I've refreshed the tar file in the > >> snapshots > >> directory. > >> http://fofredux.sourceforge.net/snapshots/fofredux-RC-0_3.tar.gz > > > > I just downloaded and installed it. It does indeed fix this. > > I think that's the last show stopper. Can we get this darn thing release= d > now? ;) > > > -- > Kevin > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2006-04-12 01:31:01
|
> On 4/11/06, Kevin <ke...@dr...> wrote: >> This is corrected in RC-0_3. I've refreshed the tar file in the >> snapshots >> directory. >> http://fofredux.sourceforge.net/snapshots/fofredux-RC-0_3.tar.gz > > I just downloaded and installed it. It does indeed fix this. I think that's the last show stopper. Can we get this darn thing release= d now? ;) --=20 Kevin |
|
From: Miles B. <mil...@gm...> - 2006-04-12 01:07:10
|
On 4/11/06, Kevin <ke...@dr...> wrote: > This is corrected in RC-0_3. I've refreshed the tar file in the snapshot= s > directory. > http://fofredux.sourceforge.net/snapshots/fofredux-RC-0_3.tar.gz I just downloaded and installed it. It does indeed fix this. Thanks, -Miles |
|
From: Kevin <ke...@dr...> - 2006-04-12 00:38:57
|
> On 4/11/06, Kevin <ke...@dr...> wrote: >> That's right. It more has to do with the revision Id in the files. >> init.php revision 1.60 and above has the fix. > > Well, I verified that my init.php is 1.60. > >> Question: When you tried out the 4/9 snapshot. Did it not work in t= he >> *exact same way*, or was the result different then previous version? > > The result was the same. I did the same steps I did before and the > item does not show up as unread. > > Below are the steps I used when I first noticed the problem. > > 1. From the panel view I clicked on the link (1 new) which is opening > "view.php?feed=3D34". > 2. Mark the item as read by clicking "Flag all Items" then click "Mark > as read", then click on the panel link. > 3. Click on the link that has all the articles for that feed > "view.php?feed=3D34&what=3Dall". > 4. Select the checkbox for the item I marked as read previously and > then click the "Mark as Unread" checkbox. > 5. Click on the Panel link and I should see the article that I marked > as unread but I don't see anything new. It shows (0 new) with no > hyperlink active. This is corrected in RC-0_3. I've refreshed the tar file in the snapshot= s directory.=20 http://fofredux.sourceforge.net/snapshots/fofredux-RC-0_3.tar.gz --=20 Kevin |
|
From: Kevin <ke...@dr...> - 2006-04-12 00:35:08
|
>> my first time jumping in here, so allow me to first say thanks for >> picking >> up this great project again. (if you guys are still active...saw that >> the >> dev mails were only up til late Feb at sf.net). >> >> In the course of doing a complete overhaul of my server this week, it >> was >> time to get a fresher feeds reader, and naturally i went with somethin= g >> i >> knew, as i had been using fof for well over a year now. >> >> After installing fofredux, and importing my feeds and their >> corresponding >> items (i don't delete anything), i noticed that updates on some of the >> feeds >> were losing their dates. They were in fact defaulting to 01-01-1970, >> and it >> was all atom (see anything at blogger.com) and RSS1.0 (e.g. slashdot), >> which >> is actually the Atom format. RSS 2.0 feeds are fine. > > My first time, too. > > I've had the same problem, which cropped up when I upgraded > my system from Fedora Core 4 to Fedora Core 5. That, of course, > changes versions of every layer, including PHP (to 5.1.2) and > mysql (to 5.0). > > I've downloaded the latest release candidate, used a new database, > and still had the problem. > > The fix that's noted (replace parse_w3cdtf with strtotime) fixes > the problem. > > I have no PHP skills at all, so I can't even begin to speculate > on the cause, but thought you folks should know that this isn't > an isolated problem. > > Thanks for all your work on fofredux. It's indispensable to me. I compared strtotime to parse_w3cdtf in as many senerios as I could. I found that strtotime works better in all cases. I've switched to using for handling all feed timestamps. --=20 Kevin |
|
From: Saul T. <sa...@ta...> - 2006-04-11 23:12:43
|
> my first time jumping in here, so allow me to first say thanks for picking > up this great project again. (if you guys are still active...saw that the > dev mails were only up til late Feb at sf.net). > > In the course of doing a complete overhaul of my server this week, it was > time to get a fresher feeds reader, and naturally i went with something i > knew, as i had been using fof for well over a year now. > > After installing fofredux, and importing my feeds and their corresponding > items (i don't delete anything), i noticed that updates on some of the feeds > were losing their dates. They were in fact defaulting to 01-01-1970, and it > was all atom (see anything at blogger.com) and RSS1.0 (e.g. slashdot), which > is actually the Atom format. RSS 2.0 feeds are fine. My first time, too. I've had the same problem, which cropped up when I upgraded my system from Fedora Core 4 to Fedora Core 5. That, of course, changes versions of every layer, including PHP (to 5.1.2) and mysql (to 5.0). I've downloaded the latest release candidate, used a new database, and still had the problem. The fix that's noted (replace parse_w3cdtf with strtotime) fixes the problem. I have no PHP skills at all, so I can't even begin to speculate on the cause, but thought you folks should know that this isn't an isolated problem. Thanks for all your work on fofredux. It's indispensable to me. - Saul -- Saul Tannenbaum Home: sa...@ta... Work: Sau...@tu... |
|
From: Miles B. <mil...@gm...> - 2006-04-11 18:16:18
|
On 4/11/06, Kevin <ke...@dr...> wrote: > That's right. It more has to do with the revision Id in the files. > init.php revision 1.60 and above has the fix. Well, I verified that my init.php is 1.60. > Question: When you tried out the 4/9 snapshot. Did it not work in the > *exact same way*, or was the result different then previous version? The result was the same. I did the same steps I did before and the item does not show up as unread. Below are the steps I used when I first noticed the problem. 1. From the panel view I clicked on the link (1 new) which is opening "view.php?feed=3D34". 2. Mark the item as read by clicking "Flag all Items" then click "Mark as read", then click on the panel link. 3. Click on the link that has all the articles for that feed "view.php?feed=3D34&what=3Dall". 4. Select the checkbox for the item I marked as read previously and then click the "Mark as Unread" checkbox. 5. Click on the Panel link and I should see the article that I marked as unread but I don't see anything new. It shows (0 new) with no hyperlink active. |
|
From: Kevin <ke...@dr...> - 2006-04-11 18:09:41
|
> On 4/11/06, Kevin <ke...@dr...> wrote: >> Are you referring to the "mark as unread" problem? The snapshot for >> 4/9 >> has the change that Andrew made.. > > Hm, I downloaded and installed the 4/9 snapshot yesterday and assumed > it was not an updated snapshot as the "mark as unread" function does > not work for me. > > Here is a directory listing with the 4/9 date on them. Is this correct? > > 2006-04-09 07:00 lib > 2006-04-09 07:00 adodb_lite > 2006-04-09 07:00 magpierss > 2006-04-09 07:00 rsswriter > 2006-04-09 07:00 tests That's right. It more has to do with the revision Id in the files.=20 init.php revision 1.60 and above has the fix. Question: When you tried out the 4/9 snapshot. Did it not work in the *exact same way*, or was the result different then previous version? --=20 Kevin |
|
From: Miles B. <mil...@gm...> - 2006-04-11 17:50:34
|
On 4/11/06, Kevin <ke...@dr...> wrote: > Are you referring to the "mark as unread" problem? The snapshot for 4/9 > has the change that Andrew made.. Hm, I downloaded and installed the 4/9 snapshot yesterday and assumed it was not an updated snapshot as the "mark as unread" function does not work for me. Here is a directory listing with the 4/9 date on them. Is this correct? 2006-04-09 07:00 lib 2006-04-09 07:00 adodb_lite 2006-04-09 07:00 magpierss 2006-04-09 07:00 rsswriter 2006-04-09 07:00 tests |
|
From: Kevin <ke...@dr...> - 2006-04-11 17:33:45
|
> I'd like to verify the fix for the "mark as read" problem. Could > someone send me the new files? > > Anonymouse cvs still has not been updated and the snapshot build > appears to be old as well. Are you referring to the "mark as unread" problem? The snapshot for 4/9 has the change that Andrew made.. --=20 Kevin |
|
From: Miles B. <mil...@gm...> - 2006-04-11 05:04:55
|
I'd like to verify the fix for the "mark as read" problem. Could someone send me the new files? Anonymouse cvs still has not been updated and the snapshot build appears to be old as well. Thanks, -Miles |
|
From: khaled A. A. <bro...@gm...> - 2006-04-09 16:39:17
|
Right just read through the various comments from above. I've not completed the design. There is still: - the full view - the mobile version - a couple of pages in the admin panel section (organise and import feeds) as well. Apart from that I think we're nearly there. I always thought that flagged items would be changed to be seen as read. They're a different beast althogether. They are your 'SAVED' items and as such they're meant to be feed items that contain information that you're going to use again and again (at least that's how I see it all). I could be wrong (and have been on multiple occasions). Have we got a battle plan as to what elements will be integrated into the programme first? The reason I'm saying this is because that way we can all play around with it and see what is necessary or what can be enhanced. I will say that I really would like the login functionality integrated into the whole system first but that's just me :). On 4/8/06, khaled Abou Alfa <bro...@gm...> wrote: > > Sorry guys I'm on holiday right now (chilling out my parent's house), but > I'll read through these tonight and get back to you guys later on about > what's been said. I've been reading the various emails to keep in check w= ith > what's going on, but to be honest I'm letting the pros get the coding don= e > and argue about the minutae details (I'd just get in the way as I couldn'= t > code myself out of a paper back). So yeah I'm around just keeping quiet := ). > > > On 4/8/06, Andrew Turner <ajt...@hi...> wrote: > > > > Correct, tags will be probably be used in v0.4+ as they offer more > > versatility, etc. > > > > Currently, the use has the option to mark: unread, read, saved. There > > was a request to put in a "Saved" RSS feed, but this will wait until > > complex searches based on tags, etc. will be implemented in 0.4. > > > > Lots of very cool features coming up in 0.4. Just waiting for any > > little bugs to shake themselves out of 0.3. Also, I don't think Khaled > > has all of the design finished, does he? > > > > Khaled? you awake? :) > > > > Andrew > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > language > > that extends applications into web and mobile media. Attend the live > > webcast > > and join the prime developer group breaking into this new coding > > territory! > > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > > <http://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642> > > _______________________________________________ > > Fofredux-devel mailing list > > Fof...@li... > > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > > > > |
|
From: Andrew T. <ajt...@hi...> - 2006-04-08 20:32:22
|
On 4/8/06, khaled Abou Alfa <bro...@gm...> wrote: > Sorry guys I'm on holiday right now (chilling out my parent's house), but > I'll read through these tonight and get back to you guys later on about > what's been said. I've been reading the various emails to keep in check w= ith > what's going on, but to be honest I'm letting the pros get the coding don= e > and argue about the minutae details (I'd just get in the way as I couldn'= t > code myself out of a paper back). So yeah I'm around just keeping quiet := ). > No worries - I just wanted to find out if the design spec was all done and the ajaxification, configuration, login/admin, view, etc. were all pretty well agreed on by all interested so we can get going on v0.4+ design once 0.3 is out. Andrew -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: khaled A. A. <bro...@gm...> - 2006-04-08 20:19:13
|
Sorry guys I'm on holiday right now (chilling out my parent's house), but I'll read through these tonight and get back to you guys later on about what's been said. I've been reading the various emails to keep in check wit= h what's going on, but to be honest I'm letting the pros get the coding done and argue about the minutae details (I'd just get in the way as I couldn't code myself out of a paper back). So yeah I'm around just keeping quiet :). On 4/8/06, Andrew Turner <ajt...@hi...> wrote: > > Correct, tags will be probably be used in v0.4+ as they offer more > versatility, etc. > > Currently, the use has the option to mark: unread, read, saved. There > was a request to put in a "Saved" RSS feed, but this will wait until > complex searches based on tags, etc. will be implemented in 0.4. > > Lots of very cool features coming up in 0.4. Just waiting for any > little bugs to shake themselves out of 0.3. Also, I don't think Khaled > has all of the design finished, does he? > > Khaled? you awake? :) > > Andrew > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Andrew T. <ajt...@hi...> - 2006-04-08 20:04:56
|
Correct, tags will be probably be used in v0.4+ as they offer more versatility, etc. Currently, the use has the option to mark: unread, read, saved. There was a request to put in a "Saved" RSS feed, but this will wait until complex searches based on tags, etc. will be implemented in 0.4. Lots of very cool features coming up in 0.4. Just waiting for any little bugs to shake themselves out of 0.3. Also, I don't think Khaled has all of the design finished, does he? Khaled? you awake? :) Andrew |
|
From: Kevin <ke...@dr...> - 2006-04-08 15:35:25
|
Evan Roth wrote: > Hey Guys, > > a quick thought on flags, while we're on the topic. in fof-r you've > changed the read flag from NULL or 1 to simply 'flag' with 0 or 1 > (currently). That's all good and fine, but here comes the hitch. I > was contemplating fixing my install, as i'd like to be able to mark > items with other flags...but not exclusively. For example, it would > be great to flag something "interesting" or "save for later" or > whatever, but not lose the read/unread status. But in the end it's > ridiculous to tack all these potential statuses on to the items > table. Perhaps 1 flag, for user-defined stuff and 1 as is for > read/unread. But then such a flag is border-line tag, but on the item > rather than feed... Any thoughts? > It's something i can jump on after the 0.3 release perhaps, as it > seems nigh, and i'm still quite under the weather. > What you describe can be easily be accomplished with tags. Tags are associated with items and it is a many-to-many relationship so you can have as many tags on an item as you want. It does not affect the read/unread status of the item. In fact we bounced around the idea of converting the read/unread/saved flag to be built in tags. > regards, > evan > > > On 4/7/06, * Andrew Turner* <ajt...@hi... > <mailto:ajt...@hi...>> wrote: > > Agreed, I've already changed the FOF_UNREAD_FLAG to 0 and changed the > get unread to check for Null or 0. What should be done then for the > future is to modify the default flag column value should be 0 and > remove the check for "is null" in the read column. > > As I mentioned, my current changes are in CVS and will be in 0.3. > Thanks again to Miles for pointing out this bug. Guess no one else has > recently tried to "mark as unread" :) > > Andrew > > On 4/7/06, Kevin < ke...@dr... <mailto:ke...@dr...>> wrote: > > > > > Well, by default, the column values are NULL, so when the "view > > > unread" gets all the NULL, then that's ok. However, the > > > fof_update_item_flag takes FOF_UNREAD_FLAG, which was NULL (I > changed > > > it in init.php to 0). > > > > > > With NULL, and the SQL query via ADODB sets the flag to 0 (at > least in > > > my testing), which then doesn't have it show up when the > get_items() > > > looks for all items with flag = NULL. > > > > > > So, ADODB on MySQL appears to set NULL as 0. > > > > I believe ADODB is doing the right thing. We defined the > FOF_UNREAD_FLAG > > as the string 'NULL', instead of using a real null data type. > ADODB sees > > the parameter is a string and escapes and quotes before sending > the query > > to the database. The database sees the string value 'NULL', > which is an > > invalid integer, and defaults to use the integer value 0. > > > > If the FOF_UNREAD_FLAG constant was changed so it's value was a > real null, > > not a string, it should fix the reported problem. > > > > That said, I think it's a good design decision to switch the unread > > indicator from NULL to 0. In SQL, NULL is special case > indicating the > > absense of any value. We are using it to indicate a value of > "unread", > > which is incorrect. > > > > > > -- > > Kevin > > > > > > > -- > Andrew Turner > ajt...@hi... > <mailto:ajt...@hi...> 42.4266N x 83.4931W > http://highearthorbit.com > <http://highearthorbit.com> Northville, Michigan, USA > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > <http://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642> > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > <mailto:Fof...@li...> > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > > |
|
From: Evan R. <eva...@gm...> - 2006-04-07 21:51:11
|
Hey Guys, a quick thought on flags, while we're on the topic. in fof-r you've change= d the read flag from NULL or 1 to simply 'flag' with 0 or 1 (currently). That's all good and fine, but here comes the hitch. I was contemplating fixing my install, as i'd like to be able to mark items with other flags...but not exclusively. For example, it would be great to flag something "interesting" or "save for later" or whatever, but not lose the read/unread status. But in the end it's ridiculous to tack all these potential statuses on to the items table. Perhaps 1 flag, for user-defined stuff and 1 as is for read/unread. But then such a flag is border-line tag= , but on the item rather than feed... Any thoughts? It's something i can jump on after the 0.3 release perhaps, as it seems nigh, and i'm still quite under the weather. regards, evan On 4/7/06, Andrew Turner <ajt...@hi...> wrote: > > Agreed, I've already changed the FOF_UNREAD_FLAG to 0 and changed the > get unread to check for Null or 0. What should be done then for the > future is to modify the default flag column value should be 0 and > remove the check for "is null" in the read column. > > As I mentioned, my current changes are in CVS and will be in 0.3. > Thanks again to Miles for pointing out this bug. Guess no one else has > recently tried to "mark as unread" :) > > Andrew > > On 4/7/06, Kevin <ke...@dr...> wrote: > > > > > Well, by default, the column values are NULL, so when the "view > > > unread" gets all the NULL, then that's ok. However, the > > > fof_update_item_flag takes FOF_UNREAD_FLAG, which was NULL (I changed > > > it in init.php to 0). > > > > > > With NULL, and the SQL query via ADODB sets the flag to 0 (at least i= n > > > my testing), which then doesn't have it show up when the get_items() > > > looks for all items with flag =3D NULL. > > > > > > So, ADODB on MySQL appears to set NULL as 0. > > > > I believe ADODB is doing the right thing. We defined the > FOF_UNREAD_FLAG > > as the string 'NULL', instead of using a real null data type. ADODB > sees > > the parameter is a string and escapes and quotes before sending the > query > > to the database. The database sees the string value 'NULL', which is a= n > > invalid integer, and defaults to use the integer value 0. > > > > If the FOF_UNREAD_FLAG constant was changed so it's value was a real > null, > > not a string, it should fix the reported problem. > > > > That said, I think it's a good design decision to switch the unread > > indicator from NULL to 0. In SQL, NULL is special case indicating the > > absense of any value. We are using it to indicate a value of "unread", > > which is incorrect. > > > > > > -- > > Kevin > > > > > > > -- > Andrew Turner > ajt...@hi... 42.4266N x 83.4931W > http://highearthorbit.com Northville, Michigan, USA > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
|
From: Andrew T. <ajt...@hi...> - 2006-04-07 20:23:03
|
Agreed, I've already changed the FOF_UNREAD_FLAG to 0 and changed the get unread to check for Null or 0. What should be done then for the future is to modify the default flag column value should be 0 and remove the check for "is null" in the read column. As I mentioned, my current changes are in CVS and will be in 0.3. Thanks again to Miles for pointing out this bug. Guess no one else has recently tried to "mark as unread" :) Andrew On 4/7/06, Kevin <ke...@dr...> wrote: > > > Well, by default, the column values are NULL, so when the "view > > unread" gets all the NULL, then that's ok. However, the > > fof_update_item_flag takes FOF_UNREAD_FLAG, which was NULL (I changed > > it in init.php to 0). > > > > With NULL, and the SQL query via ADODB sets the flag to 0 (at least in > > my testing), which then doesn't have it show up when the get_items() > > looks for all items with flag =3D NULL. > > > > So, ADODB on MySQL appears to set NULL as 0. > > I believe ADODB is doing the right thing. We defined the FOF_UNREAD_FLAG > as the string 'NULL', instead of using a real null data type. ADODB see= s > the parameter is a string and escapes and quotes before sending the query > to the database. The database sees the string value 'NULL', which is an > invalid integer, and defaults to use the integer value 0. > > If the FOF_UNREAD_FLAG constant was changed so it's value was a real null= , > not a string, it should fix the reported problem. > > That said, I think it's a good design decision to switch the unread > indicator from NULL to 0. In SQL, NULL is special case indicating the > absense of any value. We are using it to indicate a value of "unread", > which is incorrect. > > > -- > Kevin > > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2006-04-07 19:49:22
|
> Well, by default, the column values are NULL, so when the "view > unread" gets all the NULL, then that's ok. However, the > fof_update_item_flag takes FOF_UNREAD_FLAG, which was NULL (I changed > it in init.php to 0). > > With NULL, and the SQL query via ADODB sets the flag to 0 (at least in > my testing), which then doesn't have it show up when the get_items() > looks for all items with flag =3D NULL. > > So, ADODB on MySQL appears to set NULL as 0. I believe ADODB is doing the right thing. We defined the FOF_UNREAD_FLAG as the string 'NULL', instead of using a real null data type. ADODB see= s the parameter is a string and escapes and quotes before sending the query to the database. The database sees the string value 'NULL', which is an invalid integer, and defaults to use the integer value 0. If the FOF_UNREAD_FLAG constant was changed so it's value was a real null= , not a string, it should fix the reported problem. That said, I think it's a good design decision to switch the unread indicator from NULL to 0. In SQL, NULL is special case indicating the absense of any value. We are using it to indicate a value of "unread", which is incorrect. --=20 Kevin |
|
From: Andrew T. (nilspace) <nil...@us...> - 2006-04-07 18:59:32
|
Well, by default, the column values are NULL, so when the "view unread" gets all the NULL, then that's ok. However, the fof_update_item_flag takes FOF_UNREAD_FLAG, which was NULL (I changed it in init.php to 0). With NULL, and the SQL query via ADODB sets the flag to 0 (at least in my testing), which then doesn't have it show up when the get_items() looks for all items with flag =3D NULL. So, ADODB on MySQL appears to set NULL as 0. Andrew On 4/7/06, Kevin <ke...@dr...> wrote: > > > The potential solution has been committed to CVS. It will be released > > in 0.3 (which is 'imminent' and also 'emminent' ;) Please keep up the > > great effort testing the Release Candidate. > > > > Dev notes: > > For some reason, even though the item was flagged to "unread" it > > wasn't then being picked up as unread. I think this was due to ADODB > > using "0" instead of "NULL" when it set the flag in the MySQL db. > > Therefore, items flagged as 'unread' will use 0 (thought still via the > > FOF_UNREAD_FLAG) to address this issue. > > What is the behavior of items in the database with the flag still set to > the old value indicating unread (NULL)? > > > -- > Kevin > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
5 messages has been excluded from this view by a project administrator.
