myghty-users — User discussion, issues, installation, developing

[Myghty-users] in-memory components

[David G. <dg...@sp...>]

Hi,

1. What are all the possible args to interpreter.execute()?  I am not 
sure this is made explicit in the documention anywhere. For example, 
while it is evident, I don't think the argument "request_args" is 
explained anywhere.

2. I have obtained a string at the python level, and I would like to 
expand this string through the interpreter (producing another string). 
How does one do this? I am not sure this is explained anywhere.

So far, I've got

buf = "blah blah <% arg1 %> blah blah"

comp = interepreter.make_component(buf)

Now, how do I execute the component?

I tried:

outbuf = StringIO.StringIO()

interpreter.execute(comp, out_buffer = outbuf,
   request_args = { 'arg1' : 'hi there' })

but this didn't seem to work - arg1 was undefined.


Thanks alot!!

David
		

[Myghty-users] whats new in Myghty 0.95a/b/c

[mike b. <mi...@zz...>]

hey all -

as you might have noticed, Myghty versions are up to 0.95c.  Where release
0.95 was largely focused on the new <%args> and <%python> "scope"
attribute, the subsequent "letter" versions have been focused on bug fixes
as well as making some of the programmtic interfaces more complete.

    - you can abort a request with any desired HTTP return code via the
improved abort(code) method, where "code" is simply the numeric return
code or an apache return code constant from mod python.  If "code" is
None, the request simply ends and a regular "200 OK" is returned.

    - line-based comments can be added now, by specifying "#" as the very
first character on a line, similarly to the "%" syntax.  Since in
HTML::Mason you could simply do this via the passive "% #", but in
Myghty this indicates a "whitespace closure", I added this additional
syntax (plus, someone requested it).

- a generic logging method was added to request:  m.log(message). this
will log a "[Notice]" to the apache error log or a line to standard error
depending on the context.

- dhandlers were pretty much all screwed up and I am pretty sure are
working now.  included are the m.decline() method, which says, "i dont
want to handle this directory request, move up to the next highest
directory, or report a 404 if there are no more dhandlers", as well as the
m.dhandler_arg() method, which returns the requested path *relative to the
current dhandler*.  Eventually I should get around to adding a decline()
example to the documentation and possibly examples section.

and then, there are the more "goofy" methods, for programmatically dealing
with components and call stacks:

- inside of an inheriting template which normally calls m.call_next(), you
can get the next component, and that component's next component, and so
on, all in a single list, by calling m.fetch_all().

- A set of features taken from Mason is the ability to inspect the list of
components calling each other at runtime.  I'm not familiar with many
situations where one would really need to inspect "who is calling you"
given my own OO-procedural background, but here they are: the m.caller()
method will show you which component is calling the current component. 
Similarly, m.callers() returns the whole list of calling components,
m.caller_args() returns the arguments sent to the calling component, and
m.call_stack() returns the full list of StackFrame objects, which are the
internal representation of components being called.

- for locating components programmatically, you can call
m.fetch_component(path, raise_error = False) which returns the component,
or None if not found.  This performs fewer filesystem checks than calling
m.component_exists() and then m.fetch_component() separately.

- The "self" variable is fully available inside a component, in all python
sections except "global".  This is the equivalent of calling
m.current_component().  Once you have a reference to your "self", you can
inspect or set component attributes, look at your current path, and
retrieve subcomponent and method objects from your "self".  The new
methods are documented in the "Components" chapter of the docs.

- you can call a method as a top level component.  This means, if you have
your own Interpreter, you can do:

   ret = interp.execute("page.myt:get_data")

which will load up "page.myt" and call the "get_data" method, and also
return its value.  More controversially, if you have your webserver set up
to send all requests to Myghty, you can also call:

   http://mysite.com/page.myt:get_data

which will directly call the method as a web request.  Use with caution ! 
I may consider adding a configuration parameter to keep this feature off
by default.

so that's whats new.  I am hoping Myghty is working out well for the
handful of people (presumably) using it, and also I would appreciate
feedback, testimonials, and contributions as available.  I would like to
get this thing to a 1.0 release someday, where "someday" is within about a
year.  The road to 1.0 is paved with "Sites Using Myghty", "Testimonials",
and "Contributions" !  Thanks for using.

- mike

Re: [Myghty-users] Myghty documentation (0.95c), etc.

[michael b. <mi...@zz...>]

On Nov 11, 2004, at 1:08 PM, David Geller wrote:

> 1. The docs are getting better and better!

thanks!

> 2. Suggestion: many of the examples showing templates (such as under 
> Inheritance) are somwhat hard to read, as the contents of the files 
> are hard to discern from the titles. Perhaps the code itself should 
> have a tinted background?

I added a grey background, slightly lighter than the other grey boxes, 
with a little inside padding, to the code sections.  also I noticed my 
most recent stylesheet was broken on IE and I am fixing that.

> 3. Whenever there is a new release of Myghty, send a note to the 
> mailing list? That way, we'll know.

no problem.  i was announcing only major versions since i sometimes 
release every other day as I find and fix small issues...but i suppose 
the list could use the bandwidth, that is, other than the screeching 
sound of crickets chirping.....

>
> While there is still much of Myghty I do not understand, I am 
> continually impressed, and am having fun playing with it...

feel free to take a walk through the HTML::Mason docs over at 
www.masonhq.com, not to mention docs for other pyhon libraries, and 
point out things I should be doing to make it clearer.  its a real 
brain stretch for me, having worked with this kind of thing literally 
for years,  to think of what beginners really need to grok the 
concepts.


> David
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Myghty-users mailing list
> Myg...@li...
> https://lists.sourceforge.net/lists/listinfo/myghty-users

[Myghty-users] Myghty documentation (0.95c), etc.

[David G. <dg...@sp...>]

1. The docs are getting better and better!

2. Suggestion: many of the examples showing templates (such as under 
Inheritance) are somwhat hard to read, as the contents of the files are 
hard to discern from the titles. Perhaps the code itself should have a 
tinted background?

3. Whenever there is a new release of Myghty, send a note to the mailing 
list? That way, we'll know.

While there is still much of Myghty I do not understand, I am 
continually impressed, and am having fun playing with it...

David

Re: [Myghty-users] mod_python 'servlets'

[David G. <dg...@sp...>]

Hmmm. I see your point - but I wasn't thinking of the HTML-embedded 
stuff (which we would use Myghty for), but the other (command line/form 
variable wrangling, authentication, etc.). Anyway, (as usual), I am 
still trying to find the "best" way of doing things....

Searching,
David

Michael Bayer wrote:
> I'm going through the demo on the site viewing all the source code, and it
> seems to be an HTML-embedded-in-Python style of coding (such as
> http://lnx1.blue-fox.com/~dpopowich/mpstutorial/conversion?view=1).  A lot
> of the Python web frameworks I have seen seem to work like this (cherryPy,
> Quixote).
> 
> I wasnt able to get a sense of what the flow would be for a servlet that
> strictly handles business logic and passes all of its presentation off to
> another system such as Cheetah or Myghty.  You could just stick a call to
> the Interpreter right in the write_content() method, but then I wasnt
> seeing what advantage the servlet would have over a straight mod_python
> handler.  Or, you could rewrite the Myghty compiler to have Myghty pages
> compile into a class that subclasses the mod_python servlet class, but
> that would introduce a huge dependency and extra layer into the
> application without any clear advantage.
> 
>>From my brief look, it seems like two different paradigms for doing the
> same thing, rather than complimentary tools.
> 
> - mike
> 
> 
> 
> 
> 
> 
> 
>>Hi,
>>
>>I wonder if anyone has had experience with mod_python servlets. The
>>framework seems simple enough, and might be just the thing to combine
>>with myghty....(or, maybe not!). Curious about opinions.
>>
>>URL: http://home.comcast.net/~d.popowich/mpservlets/
>>
>>
>>Regards,
>>David Geller
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Sybase ASE Linux Express Edition - download now for FREE
>>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>>_______________________________________________
>>Myghty-users mailing list
>>Myg...@li...
>>https://lists.sourceforge.net/lists/listinfo/myghty-users
>>
> 
> 
> 

Re: [Myghty-users] mod_python 'servlets'

[mike b. <mi...@zz...>]

I'm going through the demo on the site viewing all the source code, and it
seems to be an HTML-embedded-in-Python style of coding (such as
http://lnx1.blue-fox.com/~dpopowich/mpstutorial/conversion?view=1).  A lot
of the Python web frameworks I have seen seem to work like this (cherryPy,
Quixote).

I wasnt able to get a sense of what the flow would be for a servlet that
strictly handles business logic and passes all of its presentation off to
another system such as Cheetah or Myghty.  You could just stick a call to
the Interpreter right in the write_content() method, but then I wasnt
seeing what advantage the servlet would have over a straight mod_python
handler.  Or, you could rewrite the Myghty compiler to have Myghty pages
compile into a class that subclasses the mod_python servlet class, but
that would introduce a huge dependency and extra layer into the
application without any clear advantage.

From my brief look, it seems like two different paradigms for doing the
same thing, rather than complimentary tools.

- mike

[Myghty-users] mod_python "servlets"

[David G. <dg...@sp...>]

Hi,

I wonder if anyone has had experience with mod_python servlets. The 
framework seems simple enough, and might be just the thing to combine 
with myghty....(or, maybe not!). Curious about opinions.

URL: http://home.comcast.net/~d.popowich/mpservlets/


Regards,
David Geller

Re: [Myghty-users] Session management

[mike b. <mi...@zz...>]

hey there -

the mod_python session handles the creation of session ID's as well as
reading/writing out the session ID from/to a cookie internally.  The last
time I went through it's source code, I seem to recall that you really
have no option on this, i.e. sending your own session ID doesnt really
work.  So I would suggest you dont specify your own session ID:

    s = Session(r)

Also, you are assigning "user" to the session as an attribute, and the
mod_python session is designed to be used as a dictionary, else it
probably wont save your data, as so:

    s['user'] = user.getUsername()

Then, if the is_new() method on session is acting strangely, that is
likely related to how it creates itself.  The last time I looked at the
source code of Session, I noticed it didnt necessarily behave the way one
would expect in that area.  So I would instead check for the presense of
the user:

    if not s.has_key('user'):
         m.comp('login.myt')

This is a better method anyway, since you really want to know if your user
is logged in, not if (s)he has a session.  What if your user logs out ? 
He or she would still have a session, but not be logged in.  This removes
any the risk of unusual 'is_new' behavior since you are setting and
checking the important state variable yourself.

Finally, you dont necessarily have to create the session in the way you
are doing it, Myghty includes the "s" variable as a global variable, if
you configure:

   PythonOption MyghtyUseSession True

in your httpd.conf file.  That way you dont have to instantiate the new
Session object, you can simply reference "s" and assign to it (though you
still have to use the "save()" method on it).

You might want to also remove the "m.write("Welcome " +
user.getUsername())" right before you redirect to "start.myt", since that
text is suppressed, and also would interfere with the redirect in a
non-buffered configuration.

Hope this helps....

- mike

> Hi,
>
> I'm trying to use the mod_python session management as following:
>
> in /autohandler
> ***********
> <%init>
>     from mod_python.Session import Session
>     s = Session(r,"xxxxxxxx")
>     if s.is_new():
>         # redirect out of here, the rest of the content
>         # in this page will not be sent
>         m.comp("login.myt")
>     else:
>         # otherwise, they are ok, deliver content
>         m.call_next()
> </%init>
>
> in component/login.myt
> ******************
> <%args>
>     username = None
>     password = None
> </%args>
>
> <B>Welcome</B><br>
>
> <form method="post" action="do_login.myt">
> <table>
>     <&|field.myt, label="Username"&>
>         <&components.myt:textfield, name="user_login", value=username &>
>     </&>
>     <&|field.myt, label="Password"&>
>         <&components.myt:password, name="password", value=password &>
>     </&>
>     <tr><td>
>         <& components.myt:button, label="Login", name="perform",
> onclick="form.submit()" &>
>     </td></tr>
> </table>
> </form>
>
> in component/do_login.myt
> *********************
> <%once>
>     from user import User
> </%once>
> <%args>
>     user_login
>     password
> </%args>
>
> <%python>
>     try:
>         user = User.getUser(user_login, password);
>         s = Session(r,"xxxxxxxx")
>         s.user = user.getUsername()
>         s.save()
>         m.write("Welcome " + user.getUsername())
>         m.send_redirect("start.myt", hard=True)
>     except Exception,e:
>         m.comp('do_report_error.myt', error = e)
> </%python>
>
>
>
>
> The result of this is that the login page is always displayed, as if the
session object hasn't been created.
> I tried to display the s object, but I have always "{}".
>
> Any idea ?
>
> Thanks
> gvillot.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Myghty-users mailing list
> Myg...@li...
> https://lists.sourceforge.net/lists/listinfo/myghty-users
>

[Myghty-users] Session management

[Georges V. <gv...@fr...>]

Hi,

I'm trying to use the mod_python session management as following:

in /autohandler
***********
<%init>
    from mod_python.Session import Session
    s = Session(r,"xxxxxxxx")
    if s.is_new():
        # redirect out of here, the rest of the content
        # in this page will not be sent
        m.comp("login.myt")
    else:
        # otherwise, they are ok, deliver content
        m.call_next()
</%init>

in component/login.myt
******************
<%args>
    username = None
    password = None
</%args>

<B>Welcome</B><br>

<form method="post" action="do_login.myt">
<table>
    <&|field.myt, label="Username"&>
        <&components.myt:textfield, name="user_login", value=username &>
    </&>
    <&|field.myt, label="Password"&>
        <&components.myt:password, name="password", value=password &>
    </&>
    <tr><td>
        <& components.myt:button, label="Login", name="perform", 
onclick="form.submit()" &>
    </td></tr>
</table>
</form>

in component/do_login.myt
*********************
<%once>
    from user import User
</%once>
<%args>
    user_login
    password
</%args>

<%python>
    try:
        user = User.getUser(user_login, password);
        s = Session(r,"xxxxxxxx")
        s.user = user.getUsername()
        s.save()
        m.write("Welcome " + user.getUsername())
        m.send_redirect("start.myt", hard=True)
    except Exception,e:
        m.comp('do_report_error.myt', error = e)
</%python>




The result of this is that the login page is always displayed, as if the 
session object hasn't been created.
I tried to display the s object, but I have always "{}".

Any idea ?

Thanks
gvillot.

[Myghty-users] coming up in .95 - scope attribute

[michael b. <mi...@zz...>]

hey there -

well its been quiet, but I see downloads continue...so I figure people 
are into this thing to some degree.

anyway, I am going to make a slight syntax shift in .95.  Not one that 
will mean the current syntax wont work, just some new semantics that I 
am hoping make things clearer, and also my own version of a particular 
semantic that recently came up on the Mason list as something they are 
doing over there with Amazon.  Then i want to make another pass through 
the documentation, utilizing this newer syntax, and try to illustrate 
more comprehensively the central concepts of the various python 
sections and component calling.  I get the impression people come by 
the site to check out myghty and are often confused and 
overwhelmed...which is certainly a big reason I dont bother with lots 
of libraries.  Docs seem to take twice as long to write as the code.

so, just as I recently added the ability to specify XML-style 
attributes inside %def and %method tags, which are synonomous with 
putting the values in a %flags section, I want to add an attribute to 
both the %python and the %args tag:  "scope".

the idea of "scope" i mostly got from doing JSP, which has this firm 
notion of application/session/request/page scope, specified as an 
attribute in the javabean tag.  you store and retrieve javabeans within 
those four scopes, i.e. level of visibility, which determines how long 
your data is going to be around and who can get to it.   This 
concept-centered syntax would in theory foster a greater conceptual 
understanding of code/variable scope with a new user, as opposed to 
learning four totally separate sets of tags that dont readily seem to 
have much in common.

I first started heading this way with myghty by taking mason's %once 
and %shared and naming them in a way I felt was clearer, i.e. %global 
and %requestlocal (but still keeping the old tags for the mason 
convert).   Since python and apache 2.0 were both threaded I added in 
%threadlocal as well.   With these names, i felt the "scope" aspect of 
the python sections was being stated more clearly (although nobody 
really mentioned either way if they liked it or not...).

now, after chatting on the mason list about a "requestargs" tag they 
are using at Amazon (yet *another* tag), i realized I just cant ignore 
the explicit "scope" concept any longer.  So I want to introduce 
<%python scope="something"> in favor of (which is a few yards shy of 
deprecating...) most of the existing special python tags, which would 
remain as shortcuts/synonyms.

So as a reward for reading/skipping my excessive rambling, the new tags 
would be as follows:

Scoped Tag                      Old Tag
-----------------               -------------
<%python scope="component">     <%python>
<%python scope="global">        <%global> / <%once>
<%python scope="thread">        <%threadlocal> / <%threadonce>
<%python scope="request">       <%requestlocal> / <%requestonce> / 
<%shared>
<%python scope="init">          <%init>
<%python scope="cleanup">       <%cleanup>

where "component" scope is the default, referring to python code inline 
with the template's text.   I like these tags because they express more 
clearly what the tag is about.  its a place to put straight python 
code, and here is the scope of that python code...as opposed to, what 
is that %threadlocal tag about ?  makes no sense to me.  at least when 
it is explicitly written as "scope", the new user has a conceptual clue 
of how to begin understanding what it means.

so then we also have a new "scope" attribute for %args, and this also 
is a new feature:

The existing args tag can be either:	<%args> or <%args 
scope="component">

The new tag is: <%args scope="request">

Which you may guess means, the "request" scoped args will always 
correspond to the original request arguments sent by the client browser 
(or whatever interface you might be using), even within %def 
components, %methods, other included pages.   Amazon apparently has 
some kind of custom mason tag that they are using with a similar 
effect, and I can remember my initial frustration with trying to 
reference request arguments inside of subcomponents with mason and 
being confused that they werent there, and then having to pass ARGS 
through to everyone in order to get them.   By having a "request 
scoped" %args tag, people can go right to the more intuitive way of 
referencing request arguments globally across a request, and by having 
it as a "scope" attribute, people will more readily be aware of the 
concept of "scope" and presumably have a head start on understanding 
"component" scoped arguments as well.

What i like most about attributes is that there are fewer tags to 
learn.   there is less "breadth" to take in when just getting started, 
and more "depth" available within each tag as one continues.

feel free to post any comments...at the very least i will be impressed 
that people actually read this whole ramble.

- mike

Re: [Myghty-users] component library

[mike b. <mi...@zz...>]

I couldn't agree with you more.  All we need is some good non-trivial and
reusable components to put in it (I'm thinking user-contributed here,
since I fear my own component ideas tend to be a bit esoteric), and I'll
put a "component library" section up.  The current examples section, I
wouldn't say those are very reuseable, they're mostly just to illustrate
how the code works.

good luck with your project.

- mike

> Hi,
>
> I think that this is very interesting project. I like Mason, but PERL is
> too dirty:) for me.
>
> I think that there should be component library available on myghty site,
> besides examples.
>
> I plan to use Myghty for small company site, just to test it.
>
> Sincerely,
>
> Gvozden
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Myghty-users mailing list
> Myg...@li...
> https://lists.sourceforge.net/lists/listinfo/myghty-users
>

[Myghty-users] component library

[Gvozden M. <gv...@ti...>]

Hi,

I think that this is very interesting project. I like Mason, but PERL is
too dirty:) for me.

I think that there should be component library available on myghty site,
besides examples.

I plan to use Myghty for small company site, just to test it.

Sincerely,

Gvozden

[Myghty-users] Myghty 0.94 released

[mike b. <mi...@zz...>]

hey all -

After much angsting and from-scratch-developing I have released Myghty
0.94, whose main feature includes an all-new caching API.  The cache can
store any kind of data, plus has a programmatic or %flags-based interface
to caching the output and return value of individual components.  The two
included implementations are dbm file and in-memory.

As usual, the Myghty documentation, which serves as the "everything plus
the kitchen sink" test platform of most of Myghty's features, has been
upgraded and is returning huge pages on www.myghty.org with lightning fast
speed using this new system (about .02 seconds per page timed on the
server side).

The caching API is built upon a genericized "container" API, with which I
also hope to base a new mod_python-independent session storage object in a
future release.  The container API can also be used to add new cache
implementations, such as a shared memory cache or size aware cache, though
I still need to complete documentation for this.

I hope to get some initial comments about the release and its stability
and performance relative to the previous release, as I reorganized some of
the code a little bit as well and fixed various glitches.  Assuming
nothing is disastruosly wrong in this release, I will soon begin a new and
wider publicity sweep in an effort to gain new Myghty users based on this
release.

- mike

Re: [Myghty-users] dhandler issues

[johnnnnnn <li...@ph...>]

> I think someone had mentioned this bug earlier, so I went and fixed
> it just now.  its in the head of cvs (which updates on sourceforge
> every five hours):

Just exported from HEAD and re-installed. Works fine. Thankyamuch.

I realize the project is still very young, so i'll keep you posted on
anything odd i notice.

On a side note, though i don't generally have much in the way of free
time, is there a need for additional developers?

-johnnnnnnnnn

Re: [Myghty-users] dhandler issues

[michael b. <mi...@zz...>]

hey john -

thanks much for being the first person (besides me) to post to the list.

I think someone had mentioned this bug earlier, so I went and fixed it 
just now.  its in the head of cvs (which updates on sourceforge every 
five hours):

request.py	version 1.31
exception.py	version 1.16
resolver.py	version 1.10

i usually dont run a script interpreter for an entire directory (messes 
with images and stuff) so I tend not to notice this kind of issue, but 
I just tested out with apache as well as command line and seems to 
work...its basically doing special logic for a new subclass of 
ComponentNotFound called PathIsDirectory in order to properly search 
for the dhandler.   let me know if you get good results.

- mike


On Sep 19, 2004, at 8:52 PM, johnnnnnn wrote:

> I might be the first person to ask for help on this listserver, so
> let's kick it off right.
>
> I have a dhandler, and i want it to handle directory-style urls.
>
> dhandler is located in <docroot>/archive/.
>
> It handles urls of the form /archive/bob.html, and even /archive/bob/,
> without a problem.
>
> When i try to hit /archive/ itself, though, i get the following error:
>
> IOError: [Errno 21] Is a directory
> in file: /usr/lib/python2.3/site-packages/myghty/resolver.py
> at line: 78
> 'return open(self.file_path).read()'
> /usr/lib/python2.3/site-packages/myghty/resolver.py:78
> /usr/lib/python2.3/site-packages/myghty/resolver.py:87
> /usr/lib/python2.3/site-packages/myghty/interp.py:246
> /usr/lib/python2.3/site-packages/myghty/interp.py:172
> /usr/lib/python2.3/site-packages/myghty/request.py:384
> /usr/lib/python2.3/site-packages/myghty/request.py:191
>
>
> Any ideas?
>
> Confs and scripts available on request.
>
> -johnnnnnnnnnn
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Myghty-users mailing list
> Myg...@li...
> https://lists.sourceforge.net/lists/listinfo/myghty-users

[Myghty-users] dhandler issues

[johnnnnnn <jo...@ph...>]

I might be the first person to ask for help on this listserver, so
let's kick it off right.

I have a dhandler, and i want it to handle directory-style urls.

dhandler is located in <docroot>/archive/.

It handles urls of the form /archive/bob.html, and even /archive/bob/,
without a problem.

When i try to hit /archive/ itself, though, i get the following error:

IOError: [Errno 21] Is a directory
in file: /usr/lib/python2.3/site-packages/myghty/resolver.py
at line: 78
'return open(self.file_path).read()'
/usr/lib/python2.3/site-packages/myghty/resolver.py:78
/usr/lib/python2.3/site-packages/myghty/resolver.py:87
/usr/lib/python2.3/site-packages/myghty/interp.py:246
/usr/lib/python2.3/site-packages/myghty/interp.py:172
/usr/lib/python2.3/site-packages/myghty/request.py:384
/usr/lib/python2.3/site-packages/myghty/request.py:191


Any ideas?

Confs and scripts available on request.

-johnnnnnnnnnn

[Myghty-users] thumbs up from the Mason team

[mike b. <mi...@zz...>]

News of Myghty made it over to the Mason list.  The full thread is
available at :

http://marc.theaimsgroup.com/?l=mason&m=109535017110499&w=2

As I was pretty certain anyway, the Mason development team is all in favor
of exploration, adaptation, and expansion of their concepts and codebase
by other projects like Myghty.  Highlights of the thread include Dave
Rolsky:

"I for one am all for it.  The person who first brought up Myghty on the
list seemed offended somehow, but I don't know why.  If you hadn't cited
your influences, that'd be one thing, but there's nothing wrong with
creating similar tools for other languages."

"[With regards to Myghty having its own way of doing things] Well, we
might steal ideas from Myghty too."

and then Jonathan Swartz:

"Agreed. Borrow away. We should link to Myghty from the Mason
wiki...maybe a related projects page?"

As the strength of an open source project is a product of the enthusiasm
of it's user base (and yes, well, its size too..), this is great news.

- mike

[Myghty-users] my favorite component tricks - unique block

[mike b. <mi...@zz...>]

since this list is, well, quiet, I thought I'd just start posting things
that I like about the myghty approach (which are of course, things I liked
about the mason approach too).

The Unique Block
---------------------------

one trick occurs when you have a component that is part of a larger page
which requires some javascript functions to be defined along with it.  An
example of this is a <SELECT> control that has some code for populating it
dynamically or allowing users to change the entries in it.  So say we have
a selector widget which provides a <SELECT> control as well as a
javascript function to replace all the entries with a list of new ones:

select.myt:
	<%doc>select.myt - a component that provides a <SELECT> control as well
as some javascript functions to manipulate it</%doc>
	<%args>
		# name of the select control
		name
	</%args>

	<script>
		// given a select box and list of items, empties the select widget and
		// writes new options into it
		function setOptions(select, items) {
			select.options.length  = 0;
			for (var i = 0; i < items.length; i++) {
				select.options[i] = new Option(items.value, items.id)
			}
		}

		// .. more javascript functions
	</script>

	<select name="<% name %>">
	</select>

you can see that if you include this <SELECT> control in five different
places on a form, the javascript function setOptions is also going to be
repeated five times, which actually doesnt break anything but does result
in excess code and pageweight in your output.   if you have javascript
code that initializes global variables for use across the page, then you
would in fact have a problem.

You could say that youll put setOptions in some other .js file or single
component include at the top of the page, but then whatever page uses your
select.myt control has to also know to include that other library, or
alternatively all your <SELECT> controls might be re-importing the .js
file for each occurence of the select.myt component, but thats still ugly.
 Also its sometimes convenient to just have a couple of javascript
functions defined along with the control that uses them, without other
pages having to know about it.

Enter the unique block, which is a super-non intrusive way to fix this:

select.myt with unique block:

	<%doc>select.myt - a component that provides a <SELECT> control as well
as some javascript functions to manipulate it</%doc>
	<%args>
		name
	</%args>

	<&| uniqueblock.myt, name=self.get_id() &>
	<script>
		function setOptions(select, items) {
			select.options.length  = 0;
			for (var i = 0; i < items.length; i++) {
				select.options[i] = new Option(items.value, items.id)
			}
		}

		// .. more javascript functions
	</script>
	</&>

	<select name="<% name %>">
	</select>

As you can see, all we did was put a <&|>..</&> construct around the
javascript part.  What that means is that whatever is within the <&> tags
is going to be output only once per request, per given block name.  the
block name here is the ID of the component, a good candidate for a unique
name.  So even if you did just have a .js file for your functions, you
still could put the <SCRIPT> statement in a unique block and cut out all
the superfluous additional calls to javascript files.

The source to uniqueblock is pretty simple too.  It keeps track of which
named blocks have been output per the current request:

uniqueblock.myt :

	<%doc>uniqueblock.myt, a component with content which outputs a named
block only once per request</%doc>
	<%args>
		# name of the unique block
		name
	</%args>
	<%requestlocal>
		# a dictionary to store which blocks have already been written
		blocks = {}
	</%requestlocal>
	<%init>
		if not blocks.has_key(name):
			m.write(m.content())
			blocks[name] = True
	</%init>

and thats all there is to it.