Lukasz Szybalski wrote:
> (...)
>
> When this happens a "SCRIPT_NAME" variable is passed to pylons
> app(this is a wsgi standard as I'm being told from wsgi list), in the
> example above the script name I believe is "/myapp/". What this does
> is tells pylons app that everything needs to be prefix
>
> On Jan 29, 2008 12:49 AM, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>>
>> Mike Orr wrote:
>> > (...)
>> >
>> > ToscaWidgets has too many dependencies; it almost doubles the size of
>> Pylons. Plus I understand the TW team wants to g
Mike Orr wrote:
> (...)
>
> ToscaWidgets has too many dependencies; it almost doubles the size of
Pylons. Plus I understand the TW team wants to get rid of a couple of
those dependencies, which Pylons has already jettisoned. lxml is
required for TW's Javascript features.
Correct. TW wants to ge
Mike Orr wrote:
> On Dec 18, 2007 1:40 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Hi Ben,
>>
>> I wholeheartedly agree and I like the idea of explicit session imports from
>> things like Beaker too so everything is explicit. The less work the user
>> has to do to find out what is actually
Mark Ramm wrote:
>> It should prolly be noted that the ini file is for deployment specific
>> settings. Nothing so critical to the apps internal structuring should
>> be in the ini like the template engine to use.
>
> Sure, that's fine and makes good sense. I will mention though that's
> not
Ben Bangert wrote:
> On Nov 25, 2007, at 3:07 PM, Alberto Valverde wrote:
>
>> "Cache decorator utilizing Beaker. Caches action or other function that
>> returns a pickle-able object as a result."
>>
>> This lead me to believe that I could happily us
Hi,
I just lost half of my hair chasing for hours an obscure bug which
finally lead me to beaker_cache after studying my app's, Paste's
wsgiwrappers, Pylons' controllers and half of the standard library's
source (well, that last part was a bit exaggerated ;), please keep this
in mind when I enter
Mike Orr wrote:
> On Nov 8, 2007 3:14 PM, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>> Mike Orr wrote:
>>> Plus, what if Pylons adds another SOP later?
>> This is reminds me of something that I've sometimes wondered about
>> pylons: wouldn't having
Mike Orr wrote:
> Plus, what if Pylons adds another SOP later?
This is reminds me of something that I've sometimes wondered about
pylons: wouldn't having just a single SOP where all the app's context
can be stored simplify much the implementation?
It would certainly make the API a little bit mo
