Re: Review of latest code

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Alexey Parshin wrote:
> 2008/7/30 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com 
> <mailto:ilya@total-knowledge.com>>
>
> So, you want to have something like:
>  
>    string csp = fullThemePath() + "HomeView.csp";
>
> ?
Except that I want a function in UUServlet that'd just return 
corresponding RequestDispatcher*.
>     It's impossible to have more then one servlet redirect to same
>     view page (by design).
>
>
> Well, when we send a request from servlet to some .csp - the request 
> should already have the data, in order for csp to just display the 
> data. If servlet sends this request to HomeView, it should store the 
> data for HomeView in the request.
>
>     /// Retrieve data
>     ///  ...
>     /// Send the request
>     request.getRequestDispatcher(csp)->forward(request, response);
>  
> Now, the thing I'm trying to avoid is generating data separately from 
> the view. I want to prevent any code duplication. If we retrieve data 
> in servlet, and store it in the request - then, for instance, both 
> LoginServlet and RegistrationServlet sending request to HomeView 
> should retrive data for HomeView not to mention that any page sending 
> request to HomeView should do the same.
Let me repeat: It's impossible to have more then one servlet redirect to 
the same view by design. If that happens,
design is violated, and that should be fixed.
OTOH, we might want to change design requirements slightly, and allow 
for such cases. However, if this occurs,
servlets redirecting to common view should have a common ancestor, which 
should have common data gathering
function. I'm not sure if this approach is good enough for what I want 
to do in the end.
> BTW, that error handling is almost transparent. The 'CString errors;' 
> declaration is in the Header.csp, the display of the error is in the 
> Footer.csp. All that is required is to add ',errors' to the list of 
> print() parameters. So, this complexity is gone.
Not really. There my be cases where display of errors will be bit more 
complex then just showing them all at the
end of a page.
> So, IMHO performance or code complexity wise my approach is better. Do 
> you have any other arguments? I'm afraid to miss something I don't 
> understand yet.
You are missing something you can't understand for a very simple reason: 
I didn't document some of
my ideas for future theme design yet :)

   Ilya.