[thelist] idea behind ajax: clear non-presentation-only-logic on server end

Mattias Thorslund mattias at thorslund.us
Mon May 29 16:35:28 CDT 2006


Zhang Weiwu wrote:
> On Thu, 25 May 2006, Hassan Schroeder wrote:
>
>   
>> Zhang Weiwu wrote:
>>
>>     
>>> Is it me or a lot of people thought about the same thing too? I have been
>>> developing web application for 3 years and I very often get messed up with
>>> "PHP generated HTML with PHP generated javascript" and ends up getting
>>> fighting 4 different escape methods and security check. This is none sense.
>>>       
>> Yes, it is. Your problem is in the "generating HTML" aspect -- just
>> don't do that. :-)
>>
>> Using an MVC-oriented templating approach like Velocity or JSP (Java
>> examples, dunno about PHP) eliminates this problem completely.
>>
>> --
>>     
>
> Thank you for trying help.
>
> That's not the way I wish to get an answer.  Perhaps I am stupid but I am
> not content with the kind of saying "just do that". I think the problem is I
> cannot write well with English for bigger topics.
>
> I worked on this very web application for 3 years, the complex structure of
> this application makes the UI very difficult to design, almost every HTML
> element is supposed to be dynamic, changing itself from a input box to a
> selection list with one mouse click. Generating the HTML from server side is
> causing a lot of detail data flowing between server and client and the
> structure is more and more difficult to maintain.  I did not hear MVC
> yesterday morning.  The current php application use the structure of UI
> layer, which is a set of objects generating the data that can be used by the
> smarty template, which in turn generate the HTML, which in turn used in the
> client side javascript to manipulate, sometimes generating javascript using
> php is necessary. The problem is not M - or C is not seperated from V ->UI,
> the business logic is even not mensioned. It is the flexible UI design
> itself made the complex structure. MVC is not solving the problem we are
> facing. I thought a better server-side technique can eliminate this kind of
> problem completely too.
>
> And thank you for someone letting me know my work will look bad with
> javascript turned off. It is impossible for my situation to meet the
> business requirement without javascript. I am not doing website design, for
> me functionality and timing supass the requirement on compatibility. Once
> compatibility is an issue, most likely this application need to have a
> seperate UI layer with reduced functions for that.
>   

Well, I certainly recognize the situation, but when that happens, it's
time to reconsider the design of the code. Reach further into OOP, look
for useful design patterns, etc.

Are you doing AJAX-style replacement of one kind of form element with
another? That certainly adds a layer of complexity.

Mattias



More information about the thelist mailing list