At 03:54 PM 11/1/2001 -0800, Tavis Rudd wrote: > > - a Webware component is simply a Python package with some > > additional conventions > >sure, but we shouldn't stipulate that the docs must be written in the >same form as Webware's (HTML). I'm thinking from the perspective of >Cheetah's docs here.
I would like to stipulate that after a standard installation, a Webware component will have a Docs/index.html in the current style, which is actually generated from the Properties.py of the component. Whether the manual(s) are generated to or written in HTML, I don't really care. What I care is that we can bind all these docs together so they are exceptionally easy to surf. > > - a WebKit plug-in is simply a Webware component loaded at > > launch time - if a WebKit plug-in needs to so some special set up, > > it does so via __init__.py like any good Python package does > >But the loading logic should be handled by the launcher script rather >than the AppServer itself. This is what I was getting at. I didn't know that was your view. You said something about how plug-ins needed to be classes (they are currently packages). The Launcher.py script is a lightweight bootstrapper that solves some of the subtle issues of Python imports, paths, etc. I'd prefer to keep it lightweight (just 60 lines) and continue to focus on AppServer and Application as we always have in the past. See more below. > > - It's "from SomeKit import SomeModule" and will not be "from > > Webware.SomeKit import SomModule" > >What do other people think about this? My dislike of it primarilly >stems from 'MiscUtils' and 'WebUtils'. If the are going to be >top-level packages they should have names that clearly identify them >as part of Webware. What clearly identifies MiddleKit and UserKit as being part of Webware any more than *Utils? The Utils suffix is used for non-framework packages. Ideally, most or all of it would get pushed back into the Python distro, but I don't have time for the campaigning and even if we did that we would need a staging area anyway. > > I agree that: > > > > - Webware should have a setup.py > > - Webware should make site-wide installation easy > > - Webware should make virtual hosting easy > > - Webware can always use better marketing including some good ideas > > from Tavis - WebKit should be more amenable and encouraging to > > writing all output to an umbrella directory that can easily live > > outside of WebKit/ - Webware needs a "Building a site" tutorial > > that takes the user through the steps of building a site, starting > > with WebKit and incorporating MiddleKit and UserKit. Basically, > > showing the canonical way to do things. > >Good! What do you think about using LaTeX? I don't have a strong opinion on LaTeX yet and won't until I try it. I won't try it for a while because I've got bigger fish in my pan. Of course, if someone contributes a "Building a Webware Site" document, they can use whatever the hell they want! ;-) > > I think that: > > > > - Webware programs like Generate.py and Launch.py need to use their > > own Webware components (I know this from experience). The Webware/ > > umbrella directory facilitates this. > >I can see your argument there, but how are externally developed >packages such as Cheetah to fit in with this model? I would think Webware Deluxe would put Webware components under Webware/ and put non-components like MySQLdb in their typical place. > > - Users who develop sites are not feeling burdened by anything > > other than: - lack of easy site wide install > > - lack of virtual hosting > > - the usual need for more docs, features and regression tests > > > - Rearranging the directory structure wrt to WebKit vs. Webware and > > modularity, will not improve a Webware user's productivity. > >I'm thinking from the perspective of a component developer here. I suspected you might come back with that, but I already have my response: I don't see the burden for component author's either. Although the lack of docs about Webware components *is* a burden. > > - more discussion as to the virtues of TaskKit > > ^ I suggest these become discussion threads in their own right. >If people in Geoff's company are using it maybe the discussion should >be about whether it should be used for SessionStore. My argument >isn't that it's not usefull, but that it's not appropriate for >SessionStore. So now for the next step: Why is it not useful and not appropriate? > > You already have: > > > > - the ability to dictate what plug-ins are loaded or not loaded via > > WebKit/Configs/AppServer.config > >But the loading procedure is handled by the AppServer and assumes a >particular directory structure. My argument is that the launcher >script is a more natural place to load the plugins from. The directory locations for plug-ins are NOT assumed. They are read from AppServer.config. It's true that the out-of-the-box config looks in Webware/, but then what did you expect? If you want the plug-ins from somewhere else, tweak AppServer.config and you're done. I can't make it any easier than that. > > - the ability to develop kick ass sites with Webware (vorbis.com, > > foreclosures.lycos.com) :-) >This WEP is definately not disputing that. Webware rocks! Thanks. -Chuck _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
