Re: Problem with webobject attributes in WOBuilder
Re: Problem with webobject attributes in WOBuilder
- Subject: Re: Problem with webobject attributes in WOBuilder
- From: Guido Neitzer <email@hidden>
- Date: Sun, 18 Jun 2006 22:26:05 +0200
On 17.06.2006, at 17:08 Uhr, Paul Lynch wrote:
I don't think that it is fair to make such tight correlation with
Cocoa. Web and desktop have quite different metaphors and
workflows, but still MVC is a good design principle to use.
True.
As many others say, a lot of application logic that is placed in
controllers really belongs in the model layer.
Right.
Distinguishing between page level components and other components
is useful. However, workflow more properly belongs in the model,
I don't think you can place "workflow" (in the meaning of possible
pageflows in the model. The model is for me about how, when and where
to store data and state of the data. Workflow depends on the state of
the application (user logged in, items in a shopping basket, ...)
and this is something not known in the model.
and validation most certainly does.
Misunderstanding. My fault. I don't do validation in the controller.
I do validation in the model. But I catch the validation errors in an
"EditPage" class and inherit from this class to build my concrete
edit pages.
More precise:
I have a base component for things common to all pages (logging,
pushing the page name somewhere accessible for other elements like
navigation and so on). Inheriting from this class, I have an
"EditPage" class with "saveChanges", "cancelEditing" and some other
methods. This page works on a standard EO, not on a concrete
subclass. It catches validation errors and collects them into an
array, it also fills a dictionary with information about the errors
(attribute name, message, ...).
In addition to this I have a component that can be bound to this
error array, showing the (localized) errors in a <ul> list. To help
the user I use a small component for setting the "labels" (the text
shown to the user in front or above an input field) in forms, which
changes its css class depending on an entry in the dict from my edit
page.
This was inspired by my reading of a very good Ruby book. I took a
lot from the book and brought it to my current (and very new) WO
project. Also I used the Wonder source code to understand better how
all this cool DirectToWeb stuff works and modelled my own hierarchy
similar but designed to my needs and to my taste.
Validation complete with localized validation messages is now a thing
of just inheriting from the right classes and putting in some of
these components. This is very efficient, fast in development and
just fun to use.
A number of these "rules" seem to me to increase complexity rather
than reduce it.
For me: I don't think so. Which rules do you think do that?
I'll end by stating that I believe that good design is whatever
results in "good" programs, where "good" means easy to develop and
maintain, as well as functional.
Yes. But I believe that every developer has his/her own rule set in
mind when writing "good code". Personally I have to force me to
follow some of my rules because "the other way" is often faster now,
but it was NEVER faster changing the code, maintaining it, finding
bugs and so on.
Yes, following a rule set (my rule set is WAY longer than the one I
posted) is always harder then "develop as you like it right now". But
for me it always paid off. A couple of weeks ago I wrote a lot of
notes for myself to use it for writing some "coding rules" for our
company and I think it will ease the development process as a whole
because it standardizes a lot of things and makes code easier to read
and to maintain.
Yes again: coding in this style is much harder but in my experience
you get much better results.
When reading your mail I thought whether you mixed two things: coding
rules for better usable code, faster development, better technical
design and the other important aspect: reacting to customer (user)
input. This is for me even easier when I follow these rigid rules! I
have better code. Better code is better and easier to change or to
extend.
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden