Re: curent status Quills ?

Michael Reitsma — 2007-03-26T22:11:54

_______________________________________________ Plone-blogging mailing list Plone-blogging-AQ2JdjIqcwT+DjiumDGGwti2O/JbrIOy< at >public.gmane.org https://lists.tomster.org/mailman/listinfo/plone-blogging

Re: curent status Quills ?

Tim Hicks — 2007-03-26T20:51:40

Development has been slow/stationary for a few months as I (and presumably others) have not had any time/finances to dedicate to it :(. Yeah, there's a branch at that is currently broken, but goes quite far towards our wish of "death to the 'evil' workflow". If you're a hacker, I'd very much encourage you to check it out and see what you can do. Hmm, I don't recall exactly what's gone on the trunk that hasn't gone on the 1.5 branch. What is it, exactly, that you want from the trunk? If nothing, I'd recommend just sticking with 1.5 for now. Once someone finishes off the traversal branch. It's "final" in all but name. The RC3 just seems to have some obscure migration bug that only some people see in combination with other products. There is even a fix for this reported in the issue collector at . Tim

curent status Quills ?

Michael Reitsma — 2007-03-26T13:30:06

test pls disregard

Nick Davis — 2007-03-23T12:02:34

just seeing if have permission to post

Re: basesyndication: xhtml content

Maurits van Rees — 2006-11-20T19:19:18

Reinout van Rees, on 2006-11-19: AFAICT (As far as I can test) this goes fine. I went ahead and committed it. See revisions 33941 of basesyndication and 33943 of Quills. If this breaks anything, shout.

Re: basesyndication: xhtml content

Reinout van Rees — 2006-11-19T00:22:58

Sounds OK. It *does* modify the interface, but it seems like a quite natural change. It puts the responsibility for ensuring good xhtml where it belongs. Safe to commit? The number one thing is that it really really needs to check whether it can safely grab getXhtml(). What I mean: it shouldn't fail if that method isn't there. Backward compatibility. Reinout

Re: PloneBookmarklets 0.5 Release

Jon Stahl — 2006-11-19T00:34:34

Shane, This is fantastic! Thanks to you and David for taking this on, and for refactoring until it's "right." (Or "right-er".) best, jon

Re: basesyndication: xhtml content

Maurits van Rees — 2006-11-18T23:25:45

Tim Hicks, on 2006-11-18: Well, there is this comment in the atom feed about the CDATA section that says: "This body below should really be xhtml instead of semi-encoded possibly unescaped strange stuff." That doesn't strike me as very encouraging. http://www.w3schools.com/xml/xml_cdata.asp says about CDATA: Everything inside a CDATA section is ignored by the parser. If your text contains a lot of "<" or "&" characters - as program code often does - the XML element can be defined as a CDATA section. This makes me think that CDATA can be handy if you're not sure what kind of data will end up in your template, but should be avoided if possible. If you know you are going to put xhtml inside that tag, there is another option. http://www.atomenabled.org/developers/syndication/#text explains the use of xhtml inside a content tag: If type="xhtml", then this element contains inline xhtml, wrapped in a div element. <div xmlns="http://www.w3.org/1999/xhtml"> AT </article> <article> <h1>PloneBookmarklets 0.5 Release</h1> <p>Shane Graber — 2006-11-18T20:44:16</p> FYI David Ray completely refactored my initial PloneBookmarklets product making it a much more Plone'ish. It's now configured as a document_action and you can configure what bookmarklets to show on your Plone blogs via the ZMI. All thanks go to David for this release! Check it out here: http://plone.org/products/plonebookmarklets Enjoy! Shane </article> <article> <h1>Re: basesyndication: xhtml content</h1> <p>Tim Hicks — 2006-11-18T16:13:47</p> Yup. Yup. It's probably best to add the method in adapters/feedentry.py, even if it just returns None by default. Yup. Well, it sounds like you *have* got a pretty good understanding of how all this fits together :). I'm not yet convinced that adding a getXhtml (or perhaps getXHTML) method is the right way to go. Somehow it feels like a special-case pollution of the (conceptual) IFeedEntry interface. Can you remind me what problem we are trying to solve? If it's just simplification of the template, then this conditioning will actually make things worse. Tim </article> <article> <h1>Re: basesyndication: xhtml content</h1> <p>Maurits van Rees — 2006-11-18T00:03:29</p> Reinout van Rees, on 2006-11-14: I'd like to keep some momentum going here. I'm trying to get a new version for my weblog off the ground. :-) But I'm not sure on how to proceed here. I don't fully grasp the relationship between fatsyndication, basesyndication and Quills or other weblog products and which parts of which products need to be changed. Well, let's think this through. I think the implementation of your idea would be as follows. Correct my if I'm wrong. - In basesyndication, add a function getXhtml() to IFeedEntry. - In Quills (as example for other weblog products) add a function getXhtml() in syndication.py. This returns the body text if the mimetype is text/html and return None otherwise. - In fatsyndication do nothing, though possibly adapters/feedentry.py could get a getXhtml() function as well and either return the same as getBody or return None or do the same as Quills above. - In basesyndication/browser/atom.xml/pt add some conditions for the content tag of an entry: if </article> <article> <h1>Re: basesyndication: author of feed item or feed</h1> <p>Maurits van Rees — 2006-11-17T23:13:55</p> Raphael Ritz, on 2006-11-15: I just committed that to fatsyndication (revision 33871). Thanks. </article> <article> <h1>Re: [OT] Re: basesyndication: author of feed itemor feed</h1> <p>Maurits van Rees — 2006-11-16T10:17:21</p> Raphael Ritz, on 2006-11-16: Ah, of course, you're right. Point taken. </article> <article> <h1>[OT] Re: basesyndication: author of feed item or feed</h1> <p>Raphael Ritz — 2006-11-16T08:24:56</p> Maurits van Rees schrieb: Though it's getting off-topic but let's continue with this little Python-101: [ritz< at >pitts ~]$ python Python 2.3.5 (#1, Jun 15 2005, 14:15:25) [GCC 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> member = "something" >>> name = '' >>> creator = 'me' >>> member and name or creator 'me' >>> If this comes as a surprize to you http://www.diveintopython.org/power_of_introspection/and_or.html#d0e9975 has more. Raphael </article> <article> <h1>Re: basesyndication: author of feed item or feed</h1> <p>Maurits van Rees — 2006-11-15T23:21:39</p> Raphael Ritz, on 2006-11-15: That won't do it. That does exactly the same as the current code. The problem is that this can return an empty string for the fullname. So you get an empty <name></name> tag team and a feed validator will complain. Most feed readers will probably just shrug their shoulders and move on to the next tag. But it is good if we try to avoid warnings from validators. </article> <article> <h1>Re: basesyndication: author of feed item or feed</h1> <p>Raphael Ritz — 2006-11-15T08:23:30</p> Raphael Ritz schrieb: uups, that was too sloppy as member can be None but return member and member.getProperty('fullname') or creator would take care of this. Sorry, Raphael </article> <article> <h1>Re: basesyndication: author of feed item or feed</h1> <p>Raphael Ritz — 2006-11-15T08:11:41</p> Maurits van Rees schrieb: [..] shorter but basically the same: return member.getProperty('fullname') or creator Raphael (just couldn't resist ...) </article> <article> <h1>Re: basesyndication: xhtml content</h1> <p>Reinout van Rees — 2006-11-14T22:29:17</p> Not sure if it is handier, but perhaps grab a getXhtml() first. If that's empty, do a getBody. If it is xhtml: put it in directly, otherwise put it in a CDATA. Difference: we don't have to deal with a lot of major/minor types of input, but just with the two that we support. On the other hand, keeping the option open is also handy. Brainstorming :-) Reinout </article> <article> <h1>Re: basesyndication: author of feed item or feed</h1> <p>Maurits van Rees — 2006-11-14T21:31:15</p> Tim Hicks, on 2006-11-14: Well, not always an author name is found. fatsyndication gives back the fullname of the Creator of a feed entry. But when that creator has not filled in a fullname in his personal preferences (/me prods Reinout...) an empty string is returned, so the name tag inside the author tag remains empty, which is not good. But I realize that exactly the same thing can be said about a feed level author. If the Creator of a feed/weblog does not have a fullname, that name tag will remain just as empty as in the case of a feed entry. So my proposed solution of introducing a getAuthor() on IFeeds may not actually solve the problem, although conceptually it is pleasing to have an author on the feed. Is there a way to solve this then? Well, fatsyndication/adapters/feedentry.py tries it already. It tries to get a fullname by trying: fullname = member.getProperty('fullname', creator) So get the fullname of the member and if no fullname is found, use the userid of the creator. But as thi </article> <article> <h1>Re: basesyndication: author of feed item or feed</h1> <p>Tim Hicks — 2006-11-14T14:14:42</p> Ok, so it sounds like the IFeed interface should indeed be extended to have a getAuthor method. The question then is what should the default implementation (i.e. fatsyndication) look like? I'd suggest that it should return None, and thus cause the author element for the feed to be absent. The justification being that the rest of the implementation will always insert an author for each IFeedEntry. As that's the case, there's no point in using up a few more cpu cycles to insert the author for the IFeed. Tim </article> <article> <h1>Re: basesyndication: xhtml content</h1> <p>Tim Hicks — 2006-11-14T14:10:22</p> Ah, good points. It now occurs to me that it may not be correct to *assume* that a call to IFeedEntry.getBody() will return (x)html. What if someone wants to syndicate some plain text, say? Perhaps that means that IFeed should be extended with a getBodyType method, which could return a tuple like (major_type, minor_type). Does that make any sense? Tim </article> </main></body></html>

gmane.comp.web.zope.plone.blogging.general

Re: curent status Quills ?

Re: curent status Quills ?

curent status Quills ?

test pls disregard

Re: basesyndication: xhtml content

Re: basesyndication: xhtml content

Re: PloneBookmarklets 0.5 Release

Re: basesyndication: xhtml content