Am Don, den 27.11.2003 schrieb Jason Mobarak um 00:04:
> Hi --
>
> I really hope that one day the world will forget about CGIs and never look back.
> This is probably my own opinion, although I'm relatively sure that others feel
> the same way. There are many better technologies for web based applications,
> I've listed many of them before. One of the best (but alas, poorly documented
> and hard to learn) is Woven from Twistedmatrix.com . Using a python web
> application framework would "only require python", if you did just a little bit
> of hacking you could bring just the parts of Twisted needed for Woven (or some
> other python web framework).
>
> You seem to have good knowledge of Python, but have you looked into other Python
> web technologies other than the tried and true but antiquated and limited CGI?
>
> One thing woven will allow you to have is have complete separation of code and
> display (MVC again).
>
> Code sections such as:
>
> def page_header(title):
> print "Content-Type: text/html"
> print
> print
> print '<html><head>'
> print '<title>',title,'</title>'
> print '</head><body>'
>
>
> Don't allow for easy expansion of webportage's look/feel. Following the
> model-view-controller design pattern the "view" would be completely abstracted
> into templates which are expanded based on how the other two facets of MVC
> interact.
>
> Currently you are using a hacked up version of portage that also hard codes HTML
> into print statements, in my opinion your search class needs to have an extra
> layer in between it and portage, so it'll be able to expand when portage
> changes.
>
> For example when you initialise the search class:
>
> def __init__ (self, ...):
>
> self.portageInterface = PortInterface()
>
> And all interaction with portage would be "proxyed" through your interface,
> i.e. a line line:
>
> full_package=portage.best(portage.portdb.xmatch("match-all",match))
>
> Would be translated to:
>
> full_package=self.portageInterface.best(self.portageInterface.xmatch("match-all",match))
>
> Using an interface intelligently could mean that in the future the only thing
> you would have to changed would be how the interface actually interacts with
> portage.
>
> I hope I've provided some good ideas that aren't to obvious or useless :-) -- I
> think the idea of a web interface to portage is really cool, I'd like to see
> webportage come to fruition but making good decisions on design now will help it
> be much more successful in the future.
>
> Toodles.
>
> -- Jason (Aether)
Jason,
thanks for your feedback. The problem (already in the "original"
portage) is that input, processing and output are mixed up in nearly
every file. For example error-messages to be given to the user are
implemented in /usr/lib/portage/site-packages/portage.py and on the
other hand some (IMHO basic) data-processing algorithms are placed into
emerge.
It's hard to build an alternative UI if design is like this - the result
is always that developers of alternative frontends simply reinvent the
wheel for their frontend: Instead of using predefined routines for basic
tasks they have to completely reimplement emerge for the application
they are building. This is a problem.
Well, my knowledge of Python is rather basic - I'm not a Guru ;) I'm
doing this project just for fun (and I don't know if I'm going to finish
it ever) and my knowledge of CGI is rather basic, too.
Thanks for your hint about Woven, I will have a look at it since it
looks like it could solve my problem about Screen-Outputs given by
emerge/portage.py
Regards,
Benjamin "beejay" Judas
--
GPG-Public-Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC31DEDD8
Key-Fingerprint:
4E65 AAFE 785B 61D8 E4D9 1671 E017 87B7 C31D EDD8
ICQ: 239829549
Jabber:[EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
