|
Hello,
My
name is Iván Socolsky, I'm 23 and I'm from Argentine. English is
not my first langage so I apologize for any error in this e-mail.
I've read "Server-side MVC Architecture" (the three articles) and
I find them great. It's a very good job. I had these ideas turning
on my head for a while and I finally found some way to bring some
order to the whole thing.
Still
there are a couple of things I don't agree with or, oh well, I just
use another method to acomplish them: - I can't help being worried
about the "one active state per session" model. I use to browse
my favourite sites with many browser windows opened at the same
time and pointing at different addresses (in the same site I mean).
For instance, I usually browse many book options simultaneously
at Amazon. - There are some elements of a website that need to be
updated all the time (I mean, there's no need to wait for a particular
event to update it). A good example that comes to my mind could
be a site map to point the user where she is at each moment. We
can not handle this simply by associating a mapController width
*every* single event in the system.
The
first issue is the most important. I've thought of an alternative
way to keep track of the user state: store it in a distributed fashion
in the client's browser. This means passing the "context" (the context
contains all attributes necessary to describe the current state
of the system) to the client to be included in every link (get and
post). This way, every request to the server could be treated as
a new request with no need to remember a history of states or a
session id... the state chart calculates the next state from a whole
package of parameters (the context) coming from the client. This
solves in an elegant way browser actions like back button and bookmarking.
History can still be maintained but only to achieve some application-specific
tasks (could we just use javascript for this ?).
The
second problem could be easily solved by using something like a
(I can't think of an appropriate name) allwaysController (please,
don't laugh :-) that is invoked before invoking the specific controller
pointed by the event.
Finally,
web applications with a high degree of interactivity are generally
built of blocks (i.e. login block, shopping cart, article body,
pollings, forums, etc). These blocks are more or less independent.
They have several events to specify user actions. I have found very
convenient to add a "source" parameter to point out who is the creator
of a certain event. This allows me to simplify the business logic
maintenance and considerably reduce the number of controllers. Of
course, this has the drawback that some "sources" are too large
and the controller code tends to be long and messy. These are just
some ideas I wanted to share with you. What do you think about all
this ?.
Once
again your article is a piece of art for any web developper. Thank
you very much.
Iván
Socolsky.
uidesign.net
reply...
I've
read "Server-side MVC Architecture" (the three articles) and I find
them great. It's a very good job. I had these ideas turning on my
head for a while and I finally found some way to bring some order
to the whole thing.
Excellent!
Still
there are a couple of things I don't agree with or, oh well, I just
use another method to acomplish them: - I can't help being worried
about the "one active state per session" model. I use to browse
my favourite sites with many browser windows opened at the same
time and pointing at different addresses (in the same site I mean).
For instance, I usually browse many book options simultaneously
at Amazon.
There
may well be cases where such a requirement exists. This would require
a different or modified architecture. In the architecture explained
it was a decision made based on risk and resources. It created a
user restriction that only one active state per session was possible.
Such a compromise is common in systems engineering.
-
There are some elements of a website that need to be updated all
the time (I mean, there's no need to wait for a particular event
to update it). A good example that comes to my mind could be a site
map to point the user where she is at each moment. We can not handle
this simply by associating a mapController width *every* single
event in the system.
I
think you are talking about the requirement for a notification mechanism.
This was adequately addressed by Pushlet technology which I highlighted
at uidesign.net about 1 year ago. Again, notification was considered
unnecessary for the architecture presented. It is not always necessary
or desirable to solve every problem on a project. A balance must
be struck.
The
first issue is the most important. I've thought of an alternative
way to keep track of the user state: store it in a distributed fashion
in the client's browser. This means passing the "context" (the context
contains all attributes necessary to describe the current state
of the system) to the client to be included in every link (get and
post). This way, every request to the server could be treated as
a new request with no need to remember a history of states or a
session id... the state chart calculates the next state from a whole
package of parameters (the context) coming from the client. This
solves in an elegant way browser actions like back button and bookmarking.
History can still be maintained but only to achieve some application-specific
tasks (could we just use javascript for this ?).
Sadly,
this is not a new idea and was actually the most common solution
adopted at Trinity Commerce before we built the server-side MVC
engine. Although you describe a new twist which involves using a
stste engine on the server. This client side storage mechanism is
considered to be inelegant because it leads to a lot of code on
the server to interrogate the stored state information arriving
from the client. It also creates encryption requirements or it creates
security holes if you don't use encryption. Naturally, it would
work but I wouldn't agree that it is a more elegant solution. Maybe
it covers more eventualities and therefore is more flexible but
it is probably less maintainable and adds risk to the project.
The
second problem could be easily solved by using something like a
(I can't think of an appropriate name) allwaysController (please,
don't laugh :-) that is invoked before invoking the specific controller
pointed by the event.
Again,
I think that a notification technology like Pushlets is the real
answer but this requires Javascript in the clien.
Finally,
web applications with a high degree of interactivity are generally
built of blocks (i.e. login block, shopping cart, article body,
pollings, forums, etc). These blocks are more or less independent.
They have several events to specify user actions. I have found very
convenient to add a "source" parameter to point out who is the creator
of a certain event. This allows me to simplify the business logic
maintenance and considerably reduce the number of controllers. Of
course, this has the drawback that some "sources" are too large
and the controller code tends to be long and messy.
Yes.
What you are highlighting is a maintenance issue when you don't
have such an elegant and fine grained partitioning scheme. The state
engine gives you very hard boundaries defined from the model which
show where the controllers are. It is not an adhoc design method
but a rigourous one. Such a rigourous scheme can seem like overkill
for a small project but it is incredibly useful on a larger project
with many developers. It becomes easy for each of them to understand
how things work and where to look for things.
These
are just some ideas I wanted to share with you. What do you think
about all this ? Once again your article is a piece of art for any
web developer.
Thank
you very much. Thankyou for the compliments. I fully accept that
there are many other architectures which are valid for web applications.
The presented architecture is based on a number of customer led
restrictions which included no client side state, completely private
and secure personal data, no client side javascript, capable of
running on a 2.x browser. I hope that helps.
Cheers
David Anderson
Editor
|
