Thanks Russell Keith-Magee's comments. Very helpful.
I think the main question is still about the whole architecture.
I'm a WebObjects developer for many years. I think WebObjects' architecture
is great:
(1) EOModel: a set of propertyList files describes the mapping of database
tables to
subclasses(EOEntities) of EnterpriseObject. This is well done
with Django;
(2) EnterpriseObjectFramework: Each entity has default get and set
functions ready (class implementation generated by eomodel files) but
can be
customised by additional implementation for concrete business logics.
(3) WebObjectFramework: pure OO model of http related elements. request and
response
are all objects, wocomponent is the abstraction of object wrap of
(html)page or page
components. An application object per web application is generated to
coordinate the
whole apps' actions while sessions are generated for individual
interaction with the app.
in session, an instance of EOEditingContext is available for
webobjects' objects(WO)
interact with enterprise objects (it is a coordinator of all database
interaction in a OO way)
A WOConponent has 3 parts: *.html an html template, a *.wod file as a
declaration file
that defines each element XYZ in the html template with the form
<webobject name=XYZ></webobject>
(eg. XYZ: WOTextField {value = session.user.lastName; size = 22; class
= Person.edit; })
Finally a class implementation file which can return the Entity class
Person, handle the
form submission etc. In the file system, it get the layout like
myPage.html
myPage.wo
myPage.html
myPage.wod
WOComponent can contain subcomponents of the same or different types,
and can
contain framework built-in wo elements like WOPupupButton etc that's
the way we
obtain the reusability.
A WOComponent can have runtime generated/fetched strings as its
template and
declaration. That makes the whole architecture very flexible.
===========
I'm not selling Apple's WebObjects, on the contrary, I'm looking for
something similar
in python. Because WebObjects currently use java and I hate it. python
is a language
a lot better than java and its' dynamic typing and runtime interprete
feature make the
app can evolve at the runtime a lot easily. And one can easily manage
the evolution
stages if we can store the class implementation into the database with
versions and
have the backend management web interface for the class graph.
I think sound reusability can not be delivered by just a working
solution. It related to
the real operation language. If a solution has simple and natural
architecture and
the built-in classes has names and methods close the the real operation
language,
then we get great reusability. Othewise our solution is basically a set
of special
dialect on top of python. and the more special of the dialect, the less
reusability
we have.
On Wed, Sep 22, 2010 at 6:36 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> On Wed, Sep 22, 2010 at 11:53 AM, Ramdas S <ram...@gmail.com> wrote:
> >
> >
> > On Wed, Sep 22, 2010 at 2:48 AM, Klaas van Schelven
> > <klaasvanschel...@gmail.com> wrote:
> >>
> >> Shawn: thanks
> >> Just started watching the video and I'm noticing my complaints are not
> >> unique.
> >>
> >> > Wow! I guess your definition of an app and expectation of
> re-usuability
> >> > from an app written by someone else
> >> > is fairly high!
> >>
> >> Actually, a big part of the problem is reusing my own apps. Mostly
> >> since all of them provide models, and every use case either needs
> >> changes to those.
> >>
> >> >
> >> > We have built serveral news sites based on Django, and a lot of code
> >> > gets
> >> > rewritten everytime, because customer requirements are very different.
> >> > We
> >> > reuse 90% of code in every project, but 10% gets rewritten or gets
> >> > writtenf
> >> > fresh.
> >> >
> >> That's interesting.
> >> Do you adapt models across your apps?
> >> Do you deal with (some kind of advanced) authorization that differs
> >> over projects?
> >
> > We don't do anything that's extra-ordinary. Tried it and it failed. While
> I
> > have not quite experimented in depth with Pylons, the problem what you
> are
> > describing about reusability exists in some way or other with every
> > platform. We've been through almost all major frameworks from Java based
> > ones to CakePHP to Rails.
> >
> > I'm sorry to disappoint, but all I do is move code between projects and
> then
> > customize models, views and urls according to the needs.
> > Even an app which is pretty well written like django-registration, I had
> to
> > customize it number of times to suite specific needs of some of my
> > customers, that my versions are impossible to reuse.
>
> I'm intrigued to know what these changes might be that they couldn't
> be integrated in a reusable fashion.
>
> I doubt even James Bennett would claim django-registration is perfect.
> Every application can be improved, or made more flexible. I'm sure
> there are points of customization that he either hasn't considered, or
> hasn't got around to implementing. This is where you, as a third
> party, can contribute back -- to engage with the builders of existing
> django apps to make them more reusable.
>
> There will also be occasions where django-registration simply isn't
> the right solution. That doesn't mean reusable apps are a failure. It
> just means that django-registration isn't the right reusable app for
> your problem. The promise of reusability isn't that every part can
> perform every task. Reusable apps only promise that if you built an
> app carefully, you'll be able to reuse it in similar circumstances in
> the future.
>
> Lastly, I can't deny that reusability has it's price. Engineering an
> application to be reusable takes more effort and planning than
> building an application as a once-off. The aim is that if you take the
> effort once to make your application reusable, the engineering payoff
> will happen quickly -- hopefully on your second build. However, if you
> have no intention of using a component a second time, then there isn't
> a whole lot of reason to spend the effort making it reusable.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
