Re: UU: Model-View-Controller
First, it isn't possible to satisfy this requirement for any <table> object w/o generating it in servlet - you must have a C++ loop of some kind.
Second, the current approach to themes that uses plain HTML and very little else (even JS) is more or less compatible with that requirement. However, nobody designs site like this anymore (IMHO). Any page that uses more or less high-level object provides objects (Flex objects, for instance) with URLs for data access. And in that case, current implementation is doing exactly what it should - data modifications in servlet, and data display in CSP.
And, finally, third. We discussed this some time ago. IIRC, it was more or less - do it your way, and that I did. And as far as I can see - it does the job correctly, it's fast and stable.
I understand that you don't like the current implementation. Fine, but I spent too much time on this code and can't just throw it away for some idea I really don't like. It's your project after all. So, I suggest - you redesign it yourself any way you like, and I would gladly help with any DB issues that may popup. That is if you still want my help. At this point, I'm taking a timeout till you need me.
2008/12/19 Ilya A. Volynets-Evenbakh <firstname.lastname@example.org>
The original theming requirement:
Themes should be designable _without_ the need for
The way CSPs look now, there is pretty much nothing but C++.
Alexey Parshin wrote:
I told you - this isn't my kind of project.
2008/12/19 Ilya A. Volynets-Evenbakh <email@example.com <mailto:firstname.lastname@example.org>>
I also told you before - this is the optimal way to do it, from many points of view. For instance, the templates for the recordset that generate HTML on the page and simplify the code would be impossible. And it makes little sence to read data from db in the controller, place it to the memory, and next moment print it to the page and deallocate. Unless, of course, you want to implement the classic MVC schema, in academic purpose.
I reviewed latest CSPs... It's no-go.
All the logic ended up in there, which pretty much
defies the theme idea. I think I'll have to insist
on CSPs _never_ having to access database directly.