| 1 |
Am Don, den 27.11.2003 schrieb Jason Mobarak um 00:04: |
| 2 |
> Hi -- |
| 3 |
> |
| 4 |
> I really hope that one day the world will forget about CGIs and never look back. |
| 5 |
> This is probably my own opinion, although I'm relatively sure that others feel |
| 6 |
> the same way. There are many better technologies for web based applications, |
| 7 |
> I've listed many of them before. One of the best (but alas, poorly documented |
| 8 |
> and hard to learn) is Woven from Twistedmatrix.com . Using a python web |
| 9 |
> application framework would "only require python", if you did just a little bit |
| 10 |
> of hacking you could bring just the parts of Twisted needed for Woven (or some |
| 11 |
> other python web framework). |
| 12 |
> |
| 13 |
> You seem to have good knowledge of Python, but have you looked into other Python |
| 14 |
> web technologies other than the tried and true but antiquated and limited CGI? |
| 15 |
> |
| 16 |
> One thing woven will allow you to have is have complete separation of code and |
| 17 |
> display (MVC again). |
| 18 |
> |
| 19 |
> Code sections such as: |
| 20 |
> |
| 21 |
> def page_header(title): |
| 22 |
> print "Content-Type: text/html" |
| 23 |
> print |
| 24 |
> print |
| 25 |
> print '<html><head>' |
| 26 |
> print '<title>',title,'</title>' |
| 27 |
> print '</head><body>' |
| 28 |
> |
| 29 |
> |
| 30 |
> Don't allow for easy expansion of webportage's look/feel. Following the |
| 31 |
> model-view-controller design pattern the "view" would be completely abstracted |
| 32 |
> into templates which are expanded based on how the other two facets of MVC |
| 33 |
> interact. |
| 34 |
> |
| 35 |
> Currently you are using a hacked up version of portage that also hard codes HTML |
| 36 |
> into print statements, in my opinion your search class needs to have an extra |
| 37 |
> layer in between it and portage, so it'll be able to expand when portage |
| 38 |
> changes. |
| 39 |
> |
| 40 |
> For example when you initialise the search class: |
| 41 |
> |
| 42 |
> def __init__ (self, ...): |
| 43 |
> |
| 44 |
> self.portageInterface = PortInterface() |
| 45 |
> |
| 46 |
> And all interaction with portage would be "proxyed" through your interface, |
| 47 |
> i.e. a line line: |
| 48 |
> |
| 49 |
> full_package=portage.best(portage.portdb.xmatch("match-all",match)) |
| 50 |
> |
| 51 |
> Would be translated to: |
| 52 |
> |
| 53 |
> full_package=self.portageInterface.best(self.portageInterface.xmatch("match-all",match)) |
| 54 |
> |
| 55 |
> Using an interface intelligently could mean that in the future the only thing |
| 56 |
> you would have to changed would be how the interface actually interacts with |
| 57 |
> portage. |
| 58 |
> |
| 59 |
> I hope I've provided some good ideas that aren't to obvious or useless :-) -- I |
| 60 |
> think the idea of a web interface to portage is really cool, I'd like to see |
| 61 |
> webportage come to fruition but making good decisions on design now will help it |
| 62 |
> be much more successful in the future. |
| 63 |
> |
| 64 |
> Toodles. |
| 65 |
> |
| 66 |
> -- Jason (Aether) |
| 67 |
|
| 68 |
Jason, |
| 69 |
|
| 70 |
thanks for your feedback. The problem (already in the "original" |
| 71 |
portage) is that input, processing and output are mixed up in nearly |
| 72 |
every file. For example error-messages to be given to the user are |
| 73 |
implemented in /usr/lib/portage/site-packages/portage.py and on the |
| 74 |
other hand some (IMHO basic) data-processing algorithms are placed into |
| 75 |
emerge. |
| 76 |
|
| 77 |
It's hard to build an alternative UI if design is like this - the result |
| 78 |
is always that developers of alternative frontends simply reinvent the |
| 79 |
wheel for their frontend: Instead of using predefined routines for basic |
| 80 |
tasks they have to completely reimplement emerge for the application |
| 81 |
they are building. This is a problem. |
| 82 |
|
| 83 |
Well, my knowledge of Python is rather basic - I'm not a Guru ;) I'm |
| 84 |
doing this project just for fun (and I don't know if I'm going to finish |
| 85 |
it ever) and my knowledge of CGI is rather basic, too. |
| 86 |
|
| 87 |
Thanks for your hint about Woven, I will have a look at it since it |
| 88 |
looks like it could solve my problem about Screen-Outputs given by |
| 89 |
emerge/portage.py |
| 90 |
|
| 91 |
Regards, |
| 92 |
Benjamin "beejay" Judas |
| 93 |
|
| 94 |
-- |
| 95 |
GPG-Public-Key: |
| 96 |
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC31DEDD8 |
| 97 |
|
| 98 |
Key-Fingerprint: |
| 99 |
4E65 AAFE 785B 61D8 E4D9 1671 E017 87B7 C31D EDD8 |
| 100 |
|
| 101 |
ICQ: 239829549 |
| 102 |
Jabber:beejay@×××××××××.de |
| 103 |
|
| 104 |
-- |
| 105 |
gentoo-dev@g.o mailing list |
Archives