-
Hi, I like to add a <py /> rule in deliverance. Work is already done: http://www.gawel.org/weblog/en/2008/12/skinning-with-pyquery-and-deliverance. I like to see that in deliverance itself without the pyquery dependency. This avoid the need of python code to instantiate your proxy/middleware. I think the rule can subclass pyref to have a better name resolution and allow to use filename="" etc. What do you think about that ? Are you accepting patch for this ? And if yes, must I raise an error when pyrefs are disallowed ? Regards, -- Gael
- Thread Outline:
-
Gael Pasgrimaud wrote: > I like to add a <py /> rule in deliverance. Work is already done: > http://www.gawel.org/weblog/en/2008/12/skinning-with-pyquery-and-deliverance. > I like to see that in deliverance itself without the pyquery > dependency. This avoid the need of python code to instantiate your > proxy/middleware. > > I think the rule can subclass pyref to have a better name resolution > and allow to use filename="" etc. > > What do you think about that ? Are you accepting patch for this ? And > if yes, must I raise an error when pyrefs are disallowed ? Yes, I noticed your blog post. I've been interested in some kind of arbitrary output modification for a while, and pyquery seems like a good way to phrase that. Though I also think it's young and has some API changes I'd like to see (including using lxml.html instead of just lxml.etree, though I emailed the author about that and I think he's going to make that change). Certainly it should use the permission setting for pyref -- that's intended to be a way of blocking off arbitrary Python, so you could give access to the config file to somewhat untrusted people. Also it should use that code, since pyref allows things like non-module files. I might imagine it like: <response pyquery="{pyref}" />, where <response /> is for arbitrary modifications of the response. Maybe other kinds of transformations would be allowed at some time under other attributes. There needs to be a way to include other config files to really make pyref security restrictions interesting, and probably that setting needs to be more localized, so you can allow pyref in someplace and not in others. For instance, if you had pyref and includes, you might do: <include pyref="file:find_rules.py:find_rules" pyarg-rulebase="/etc/rules" allow-pyref="false" /> And then find_rules.py has: def find_rules(req, rulebase): host = req.host.split(':')[0].lower() return os.path.join(rulebase, host, 'rules.xml') But anyway, that's an aside for this case. Ian-
On Thu, Dec 18, 2008 at 8:44 PM, Ian Bicking <ianb@...> wrote: > Gael Pasgrimaud wrote: >> >> I like to add a <py /> rule in deliverance. Work is already done: >> >> http://www.gawel.org/weblog/en/2008/12/skinning-with-pyquery-and-deliverance. >> I like to see that in deliverance itself without the pyquery >> dependency. This avoid the need of python code to instantiate your >> proxy/middleware. >> >> I think the rule can subclass pyref to have a better name resolution >> and allow to use filename="" etc. >> >> What do you think about that ? Are you accepting patch for this ? And >> if yes, must I raise an error when pyrefs are disallowed ? > > > Yes, I noticed your blog post. I've been interested in some kind of > arbitrary output modification for a while, and pyquery seems like a good way > to phrase that. Though I also think it's young and has some API changes I'd > like to see (including using lxml.html instead of just lxml.etree, though I > emailed the author about that and I think he's going to make that change). > In 0.3 you can choose the parser to use (I'm also a pyquery contributor). See http://pyquery.org/#using-different-parsers I've tried to make the api more pythonic but can't find a way to make a property callable too. What I like to see in pyquery: doc.html(); doc.html('<div></div>'); doc.html; doc.html = '<div></div>' Pointers are welcome.. Although I'm not sure this is doable. > Certainly it should use the permission setting for pyref -- that's intended > to be a way of blocking off arbitrary Python, so you could give access to > the config file to somewhat untrusted people. Also it should use that code, > since pyref allows things like non-module files. I might imagine it like: > > <response pyquery="{pyref}" />, where <response /> is for arbitrary > modifications of the response. Maybe other kinds of transformations would > be allowed at some time under other attributes. > You're right. The experience i have with deliverance is that a few changes to the content's response (eg wrap your content body in a <div id="main"></div> or change id="sphinxcolumn" to id="column") help a lot to apply a default theme without other specific rules / css. Maybe a kind of before hook can be useful to modify the content's response before applying rules: <ruleset before="file:before.py:before" /> and then in before.py: def before(req, resp): doc = PyQuery(resp.lxml) if req.path_info.startswith('/blog'): doc('#footer').remove() ... By the way, I think a pyquery dependency is not needed since you can instantiate a PyQuery object with a lxml node. So to use it you just need to have pyquery in your sys.path and the lxml tree available in pyref's arguments (a resp.lxml property like in webtest could be a good idea.). This will allow people to use both lxml and pyquery api. Regards, -- Gael
-
Gael Pasgrimaud wrote: > On Thu, Dec 18, 2008 at 8:44 PM, Ian Bicking <ianb@...> wrote: >> Gael Pasgrimaud wrote: >>> I like to add a <py /> rule in deliverance. Work is already done: >>> >>> http://www.gawel.org/weblog/en/2008/12/skinning-with-pyquery-and-deliverance. >>> I like to see that in deliverance itself without the pyquery >>> dependency. This avoid the need of python code to instantiate your >>> proxy/middleware. >>> >>> I think the rule can subclass pyref to have a better name resolution >>> and allow to use filename="" etc. >>> >>> What do you think about that ? Are you accepting patch for this ? And >>> if yes, must I raise an error when pyrefs are disallowed ? >> >> Yes, I noticed your blog post. I've been interested in some kind of >> arbitrary output modification for a while, and pyquery seems like a good way >> to phrase that. Though I also think it's young and has some API changes I'd >> like to see (including using lxml.html instead of just lxml.etree, though I >> emailed the author about that and I think he's going to make that change). >> > > In 0.3 you can choose the parser to use (I'm also a pyquery > contributor). See http://pyquery.org/#using-different-parsers > > I've tried to make the api more pythonic but can't find a way to make > a property callable too. > What I like to see in pyquery: > > doc.html(); doc.html('<div></div>'); doc.html; doc.html = '<div></div>' > > Pointers are welcome.. Although I'm not sure this is doable. In SQLObject I made a .set() method, which just sets attributes. So it'd be like: doc.html doc.set(html='new value') The method just loops through **kw and uses setattr (though you might want to check for the existence of attributes/properties in addition to avoid misspellings). Obviously you'd still allow setting doc.html, you just couldn't chain that. >> Certainly it should use the permission setting for pyref -- that's intended >> to be a way of blocking off arbitrary Python, so you could give access to >> the config file to somewhat untrusted people. Also it should use that code, >> since pyref allows things like non-module files. I might imagine it like: >> >> <response pyquery="{pyref}" />, where <response /> is for arbitrary >> modifications of the response. Maybe other kinds of transformations would >> be allowed at some time under other attributes. >> > > You're right. The experience i have with deliverance is that a few > changes to the content's response (eg wrap your content body in a <div > id="main"></div> or change id="sphinxcolumn" to id="column") help a > lot to apply a default theme without other specific rules / css. > Maybe a kind of before hook can be useful to modify the content's > response before applying rules: > > <ruleset before="file:before.py:before" /> > > and then in before.py: > > def before(req, resp): > doc = PyQuery(resp.lxml) > if req.path_info.startswith('/blog'): > doc('#footer').remove() > ... > > By the way, I think a pyquery dependency is not needed since you can > instantiate a PyQuery object with a lxml node. So to use it you just > need to have pyquery in your sys.path and the lxml tree available in > pyref's arguments (a resp.lxml property like in webtest could be a > good idea.). > This will allow people to use both lxml and pyquery api. Hmm... when you mention it this way, I think running it as part of the rules makes sense. Then it would be part of the ordering of the rules, so "before" or "after" just means at the start or end of a rule. So maybe <transform>? Though... you might want to transform the theme or the content. Probably somewhat counter-intuitively, usually you want to transform the theme, which also happens to become the response (while the content is ultimately thrown away). I guess there could be an attribute to indicate which it would work on, defaulting to the theme, and the documentation would need to explain this some (mostly suggesting that you apply transformations at the end of the rules). In this case Deliverance would be giving its internal lxml documents to the transformation functions, just wrapped in PyQuery (PyQuery wouldn't parse or serialize the documents at all). Ian
-
On Sat, Dec 27, 2008 at 8:37 PM, Ian Bicking <ianb@...> wrote: > Gael Pasgrimaud wrote: >> >> On Thu, Dec 18, 2008 at 8:44 PM, Ian Bicking <ianb@...> wrote: >>> >>> Gael Pasgrimaud wrote: >>>> >>>> I like to add a <py /> rule in deliverance. Work is already done: >>>> >>>> >>>> http://www.gawel.org/weblog/en/2008/12/skinning-with-pyquery-and-deliverance. >>>> I like to see that in deliverance itself without the pyquery >>>> dependency. This avoid the need of python code to instantiate your >>>> proxy/middleware. >>>> >>>> I think the rule can subclass pyref to have a better name resolution >>>> and allow to use filename="" etc. >>>> >>>> What do you think about that ? Are you accepting patch for this ? And >>>> if yes, must I raise an error when pyrefs are disallowed ? >>> >>> Yes, I noticed your blog post. I've been interested in some kind of >>> arbitrary output modification for a while, and pyquery seems like a good >>> way >>> to phrase that. Though I also think it's young and has some API changes >>> I'd >>> like to see (including using lxml.html instead of just lxml.etree, though >>> I >>> emailed the author about that and I think he's going to make that >>> change). >>> >> >> In 0.3 you can choose the parser to use (I'm also a pyquery >> contributor). See http://pyquery.org/#using-different-parsers >> >> I've tried to make the api more pythonic but can't find a way to make >> a property callable too. >> What I like to see in pyquery: >> >> doc.html(); doc.html('<div></div>'); doc.html; doc.html = '<div></div>' >> >> Pointers are welcome.. Although I'm not sure this is doable. > > In SQLObject I made a .set() method, which just sets attributes. So it'd be > like: > > doc.html > > doc.set(html='new value') > > The method just loops through **kw and uses setattr (though you might want > to check for the existence of attributes/properties in addition to avoid > misspellings). Obviously you'd still allow setting doc.html, you just > couldn't chain that. > The problem is that we want to be full compatible with the jQuery api. So html must be a method and an attribute. I've found a workaround but it's not efficient (i need to evaluate the result and return a callable subclasse of the original result's type). So, for now, I think the pyquery's api will remain as this... >>> Certainly it should use the permission setting for pyref -- that's >>> intended >>> to be a way of blocking off arbitrary Python, so you could give access to >>> the config file to somewhat untrusted people. Also it should use that >>> code, >>> since pyref allows things like non-module files. I might imagine it >>> like: >>> >>> <response pyquery="{pyref}" />, where <response /> is for arbitrary >>> modifications of the response. Maybe other kinds of transformations >>> would >>> be allowed at some time under other attributes. >>> >> >> You're right. The experience i have with deliverance is that a few >> changes to the content's response (eg wrap your content body in a <div >> id="main"></div> or change id="sphinxcolumn" to id="column") help a >> lot to apply a default theme without other specific rules / css. >> Maybe a kind of before hook can be useful to modify the content's >> response before applying rules: >> >> <ruleset before="file:before.py:before" /> >> >> and then in before.py: >> >> def before(req, resp): >> doc = PyQuery(resp.lxml) >> if req.path_info.startswith('/blog'): >> doc('#footer').remove() >> ... >> >> By the way, I think a pyquery dependency is not needed since you can >> instantiate a PyQuery object with a lxml node. So to use it you just >> need to have pyquery in your sys.path and the lxml tree available in >> pyref's arguments (a resp.lxml property like in webtest could be a >> good idea.). >> This will allow people to use both lxml and pyquery api. > > Hmm... when you mention it this way, I think running it as part of the rules > makes sense. Then it would be part of the ordering of the rules, so > "before" or "after" just means at the start or end of a rule. > > So maybe <transform>? Though... you might want to transform the theme or > the content. Probably somewhat counter-intuitively, usually you want to > transform the theme, which also happens to become the response (while the > content is ultimately thrown away). I guess there could be an attribute to > indicate which it would work on, defaulting to the theme, and the > documentation would need to explain this some (mostly suggesting that you > apply transformations at the end of the rules). > > In this case Deliverance would be giving its internal lxml documents to the > transformation functions, just wrapped in PyQuery (PyQuery wouldn't parse or > serialize the documents at all). > It seems that it's what I do in my blog post. A rule is only a function with theme and content as arguments. So why reinventing the wheel ? You already have all stuff needed. You just need a new kind of rule aware of pyrefs and documentation to explain what theme and content are. The only thing missing (as you noticed above) is that providing the original content's response (and request ?) as argument can be useful. -- Gael
-
-
-