Re: an alternative approach to the standard mvc
What's wrong with Element Construction Set (http://jakarta.apache.org/ecs/index.html) ? IMHO the whole point of MVC is to separate presentation logic from business logic. Your solution seems to only abstract html construction via java object manipulation. There's much more to MVC than just that. It's no replacement for MVC. Overall the idea is nice but not new. Sorry for not being supportive, just my opinion. --V. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 03, 2001 3:48 PM Subject: an alternative approach to the standard mvc Hi everyone, For those who have built a web application using the standard MVC pattern I'm sure you have found it can be quite a tedious and cumbersome solution. The constant need to jump in and out of html/java and the messy process of moving data between the model, the controller and the view is not a pretty one. I've tried to come up with a better solution for implementing MVC. Objective html is a toolkit that aims at making html form development similar to the code you write for something like Java-Swing. Instead of having 3 components for each form, i.e. the jsp page, the javabean and the controller, I've pull all these components back together so you have the model, controller and view in the one class file. If you check out my example its a much more intuitive and easy to follow solution then having the standard 3 parts solution. Some advantages of Objective HTML are: - Form data is much easily handled and much more intuitive - No need to have 3 pieces of code like MVC (jsp, bean, controller), instead most of your code lies in one class - Less knowledge of html required, most of the messy html code is abstracted in the Java objects - Much more Object-Orientated for the discipline freaks - Fully open source I hope some people can try out this toolkitout and let me know if it is useful to them and what I can do to improve it. Check out the website at http://objectivehtml.sourceforge.net Cheers, Keith -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: an alternative approach to the standard mvc
Well that particular project you referred its just a generic construction set for Html or Xml. The toolkit I've proposed goes beyond that, my objects actually have state and are true objects in the OO sense. The toolkit does more than just abstract html construction via java manipulation, if thats what you think it does then you've missed the whole point. I welcome your comment though, cause it means I haven't explained the purposes toolkit well enough. I know what MVC is meant to do, in theory it sounds very good but one of the problems is that a lot of the times business logic drives the presentation. What I'm trying to do is make the view/model/controller a lot closer to each other, i.e. I'm trying to couple the parts that they have in common and trying to decouple the parts that should be seperated. In the normal MVC pattern you got the model, view and controller all seperated, but the reality is that there is strong relationship between all of them. Before you make another comment, please have a look at what the method updateData() tries to do and look at how you much easier you access the data from the form and how you can manipulate the presentation of the form. btw.. my solution does seperate presentation from the logic. All the presentation is held in the objects themselves. Though I haven't planned it, its possible that these objects at a latter stage will render something else instead of Html. Vladimir Grishchenko [EMAIL PROTECTED] on 04/12/2001 11:29:39 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc What's wrong with Element Construction Set (http://jakarta.apache.org/ecs/index.html) ? IMHO the whole point of MVC is to separate presentation logic from business logic. Your solution seems to only abstract html construction via java object manipulation. There's much more to MVC than just that. It's no replacement for MVC. Overall the idea is nice but not new. Sorry for not being supportive, just my opinion. --V. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 03, 2001 3:48 PM Subject: an alternative approach to the standard mvc Hi everyone, For those who have built a web application using the standard MVC pattern I'm sure you have found it can be quite a tedious and cumbersome solution. The constant need to jump in and out of html/java and the messy process of moving data between the model, the controller and the view is not a pretty one. I've tried to come up with a better solution for implementing MVC. Objective html is a toolkit that aims at making html form development similar to the code you write for something like Java-Swing. Instead of having 3 components for each form, i.e. the jsp page, the javabean and the controller, I've pull all these components back together so you have the model, controller and view in the one class file. If you check out my example its a much more intuitive and easy to follow solution then having the standard 3 parts solution. Some advantages of Objective HTML are: - Form data is much easily handled and much more intuitive - No need to have 3 pieces of code like MVC (jsp, bean, controller), instead most of your code lies in one class - Less knowledge of html required, most of the messy html code is abstracted in the Java objects - Much more Object-Orientated for the discipline freaks - Fully open source I hope some people can try out this toolkitout and let me know if it is useful to them and what I can do to improve it. Check out the website at http://objectivehtml.sourceforge.net Cheers, Keith -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: an alternative approach to the standard mvc
Well, after taking second look I agree that ECS is more primitive. Don't get me wrong, I'm just trying to say that making HTML construction done via Java objects and providing convenience methods for extracting request parameters is no replacement for MVC in a general case. Say, I want to change the look and feel of my web site (an old example...), do I need to rewrite all my classes that inherit from OHTML and have them recompiled? If it's a simple project it's probably OK, but as a Java software developer I don't want to create html designs (whether or not via html directly or using OHTML classes) if there are people on the project who are good at it, and in their turn those people won't feel comfortable dealing with Java code. Again, don't get me wrong, the stuff you've created is great, but unfortunately it's not a universal MVC replacement. Just my 2 c. Vlad. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 03, 2001 4:46 PM Subject: Re: an alternative approach to the standard mvc Well that particular project you referred its just a generic construction set for Html or Xml. The toolkit I've proposed goes beyond that, my objects actually have state and are true objects in the OO sense. The toolkit does more than just abstract html construction via java manipulation, if thats what you think it does then you've missed the whole point. I welcome your comment though, cause it means I haven't explained the purposes toolkit well enough. I know what MVC is meant to do, in theory it sounds very good but one of the problems is that a lot of the times business logic drives the presentation. What I'm trying to do is make the view/model/controller a lot closer to each other, i.e. I'm trying to couple the parts that they have in common and trying to decouple the parts that should be seperated. In the normal MVC pattern you got the model, view and controller all seperated, but the reality is that there is strong relationship between all of them. Before you make another comment, please have a look at what the method updateData() tries to do and look at how you much easier you access the data from the form and how you can manipulate the presentation of the form. btw.. my solution does seperate presentation from the logic. All the presentation is held in the objects themselves. Though I haven't planned it, its possible that these objects at a latter stage will render something else instead of Html. Vladimir Grishchenko [EMAIL PROTECTED] on 04/12/2001 11:29:39 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc What's wrong with Element Construction Set (http://jakarta.apache.org/ecs/index.html) ? IMHO the whole point of MVC is to separate presentation logic from business logic. Your solution seems to only abstract html construction via java object manipulation. There's much more to MVC than just that. It's no replacement for MVC. Overall the idea is nice but not new. Sorry for not being supportive, just my opinion. --V. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 03, 2001 3:48 PM Subject: an alternative approach to the standard mvc Hi everyone, For those who have built a web application using the standard MVC pattern I'm sure you have found it can be quite a tedious and cumbersome solution. The constant need to jump in and out of html/java and the messy process of moving data between the model, the controller and the view is not a pretty one. I've tried to come up with a better solution for implementing MVC. Objective html is a toolkit that aims at making html form development similar to the code you write for something like Java-Swing. Instead of having 3 components for each form, i.e. the jsp page, the javabean and the controller, I've pull all these components back together so you have the model, controller and view in the one class file. If you check out my example its a much more intuitive and easy to follow solution then having the standard 3 parts solution. Some advantages of Objective HTML are: - Form data is much easily handled and much more intuitive - No need to have 3 pieces of code like MVC (jsp, bean, controller), instead most of your code lies in one class - Less knowledge of html required, most of the messy html code is abstracted in the Java objects - Much more Object-Orientated for the discipline freaks - Fully open source I hope some people can try out this toolkitout and let me know if it is useful to them and what I can do to improve it. Check out the website at http://objectivehtml.sourceforge.net Cheers, Keith -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles
Re: an alternative approach to the standard mvc
Well yes like any solution there are strengths and weaknesses. You're absolutely correct here, if you do need to change your html then you will need to change your java code and recompile. But mind you the Jsp is only one part of the overall solution (I'm talking in the traditional mvc sense), you still have your JavaBean and Controller classes. So even if you save time not having to recompile your Jsps, for the most of your development time you're writing the code for the JavaBean and Controller, so you have to recompile anyway. The toolkit is designed purely for the html form only, from my own experiences there's not all that much fancy html stuff you can do in the form itelf, around the form yes! and the html developer is still free to do that in this toolkit. If you use style-sheets extensively it wouldn't be that hard to get around the issues you have raised. I'm not suggesting for a second that this toolkit was meant to solve everyone's problems, but it may help some developers who develop the Html and the Business Code themselves. If you have a person developing all the Html code, and another writing the Java code then its probably not appropriate. Thanks for your input Vlad, its much appreciated. Keith Vladimir Grishchenko [EMAIL PROTECTED] on 04/12/2001 12:38:29 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc Well, after taking second look I agree that ECS is more primitive. Don't get me wrong, I'm just trying to say that making HTML construction done via Java objects and providing convenience methods for extracting request parameters is no replacement for MVC in a general case. Say, I want to change the look and feel of my web site (an old example...), do I need to rewrite all my classes that inherit from OHTML and have them recompiled? If it's a simple project it's probably OK, but as a Java software developer I don't want to create html designs (whether or not via html directly or using OHTML classes) if there are people on the project who are good at it, and in their turn those people won't feel comfortable dealing with Java code. Again, don't get me wrong, the stuff you've created is great, but unfortunately it's not a universal MVC replacement. Just my 2 c. Vlad. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 03, 2001 4:46 PM Subject: Re: an alternative approach to the standard mvc Well that particular project you referred its just a generic construction set for Html or Xml. The toolkit I've proposed goes beyond that, my objects actually have state and are true objects in the OO sense. The toolkit does more than just abstract html construction via java manipulation, if thats what you think it does then you've missed the whole point. I welcome your comment though, cause it means I haven't explained the purposes toolkit well enough. I know what MVC is meant to do, in theory it sounds very good but one of the problems is that a lot of the times business logic drives the presentation. What I'm trying to do is make the view/model/controller a lot closer to each other, i.e. I'm trying to couple the parts that they have in common and trying to decouple the parts that should be seperated. In the normal MVC pattern you got the model, view and controller all seperated, but the reality is that there is strong relationship between all of them. Before you make another comment, please have a look at what the method updateData() tries to do and look at how you much easier you access the data from the form and how you can manipulate the presentation of the form. btw.. my solution does seperate presentation from the logic. All the presentation is held in the objects themselves. Though I haven't planned it, its possible that these objects at a latter stage will render something else instead of Html. Vladimir Grishchenko [EMAIL PROTECTED] on 04/12/2001 11:29:39 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc What's wrong with Element Construction Set (http://jakarta.apache.org/ecs/index.html) ? IMHO the whole point of MVC is to separate presentation logic from business logic. Your solution seems to only abstract html construction via java object manipulation. There's much more to MVC than just that. It's no replacement for MVC. Overall the idea is nice but not new. Sorry for not being supportive, just my opinion. --V. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 03, 2001 3:48 PM Subject: an alternative approach to the standard mvc Hi everyone, For those who have built a web application using the standard MVC pattern I'm sure you have found it can be quite a tedious and cumbersome
Re: an alternative approach to the standard mvc
Adding to what Vlad said, consider a web application that will be deployed in the ASP model: multiple companies will use the same service (for example email, contact list, calendar), but they each want their own look feel. In this case, the view must absolutely be separate from the controller and the model. You are better off putting the extra work into the control and keeping your model and view as simple as possible. --- [EMAIL PROTECTED] wrote: Well yes like any solution there are strengths and weaknesses. You're absolutely correct here, if you do need to change your html then you will need to change your java code and recompile. But mind you the Jsp is only one part of the overall solution (I'm talking in the traditional mvc sense), you still have your JavaBean and Controller classes. So even if you save time not having to recompile your Jsps, for the most of your development time you're writing the code for the JavaBean and Controller, so you have to recompile anyway. The toolkit is designed purely for the html form only, from my own experiences there's not all that much fancy html stuff you can do in the form itelf, around the form yes! and the html developer is still free to do that in this toolkit. If you use style-sheets extensively it wouldn't be that hard to get around the issues you have raised. I'm not suggesting for a second that this toolkit was meant to solve everyone's problems, but it may help some developers who develop the Html and the Business Code themselves. If you have a person developing all the Html code, and another writing the Java code then its probably not appropriate. Thanks for your input Vlad, its much appreciated. Keith Vladimir Grishchenko [EMAIL PROTECTED] on 04/12/2001 12:38:29 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc Well, after taking second look I agree that ECS is more primitive. Don't get me wrong, I'm just trying to say that making HTML construction done via Java objects and providing convenience methods for extracting request parameters is no replacement for MVC in a general case. Say, I want to change the look and feel of my web site (an old example...), do I need to rewrite all my classes that inherit from OHTML and have them recompiled? If it's a simple project it's probably OK, but as a Java software developer I don't want to create html designs (whether or not via html directly or using OHTML classes) if there are people on the project who are good at it, and in their turn those people won't feel comfortable dealing with Java code. Again, don't get me wrong, the stuff you've created is great, but unfortunately it's not a universal MVC replacement. Just my 2 c. Vlad. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 03, 2001 4:46 PM Subject: Re: an alternative approach to the standard mvc Well that particular project you referred its just a generic construction set for Html or Xml. The toolkit I've proposed goes beyond that, my objects actually have state and are true objects in the OO sense. The toolkit does more than just abstract html construction via java manipulation, if thats what you think it does then you've missed the whole point. I welcome your comment though, cause it means I haven't explained the purposes toolkit well enough. I know what MVC is meant to do, in theory it sounds very good but one of the problems is that a lot of the times business logic drives the presentation. What I'm trying to do is make the view/model/controller a lot closer to each other, i.e. I'm trying to couple the parts that they have in common and trying to decouple the parts that should be seperated. In the normal MVC pattern you got the model, view and controller all seperated, but the reality is that there is strong relationship between all of them. Before you make another comment, please have a look at what the method updateData() tries to do and look at how you much easier you access the data from the form and how you can manipulate the presentation of the form. btw.. my solution does seperate presentation from the logic. All the presentation is held in the objects themselves. Though I haven't planned it, its possible that these objects at a latter stage will render something else instead of Html. Vladimir Grishchenko [EMAIL PROTECTED] on 04/12/2001 11:29:39 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc What's wrong with Element Construction Set (http://jakarta.apache.org/ecs/index.html) ? IMHO the whole point of MVC is to separate presentation logic from
Re: an alternative approach to the standard mvc
Hi August, Your examples are very specific and are aimed where the traditional mvc pattern would serve well. But there also many situations where having to write a jsp, a bean and a controller just proves to be a very tedious and cumbersome process. I know it, I've done it! This toolkit is just an alternative approach, if you look closely its really a skewed mvc implementation. Keith August Detlefsen [EMAIL PROTECTED] on 04/12/2001 13:49:48 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc Adding to what Vlad said, consider a web application that will be deployed in the ASP model: multiple companies will use the same service (for example email, contact list, calendar), but they each want their own look feel. In this case, the view must absolutely be separate from the controller and the model. You are better off putting the extra work into the control and keeping your model and view as simple as possible. --- [EMAIL PROTECTED] wrote: Well yes like any solution there are strengths and weaknesses. You're absolutely correct here, if you do need to change your html then you will need to change your java code and recompile. But mind you the Jsp is only one part of the overall solution (I'm talking in the traditional mvc sense), you still have your JavaBean and Controller classes. So even if you save time not having to recompile your Jsps, for the most of your development time you're writing the code for the JavaBean and Controller, so you have to recompile anyway. The toolkit is designed purely for the html form only, from my own experiences there's not all that much fancy html stuff you can do in the form itelf, around the form yes! and the html developer is still free to do that in this toolkit. If you use style-sheets extensively it wouldn't be that hard to get around the issues you have raised. I'm not suggesting for a second that this toolkit was meant to solve everyone's problems, but it may help some developers who develop the Html and the Business Code themselves. If you have a person developing all the Html code, and another writing the Java code then its probably not appropriate. Thanks for your input Vlad, its much appreciated. Keith Vladimir Grishchenko [EMAIL PROTECTED] on 04/12/2001 12:38:29 Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] cc: Subject: Re: an alternative approach to the standard mvc Well, after taking second look I agree that ECS is more primitive. Don't get me wrong, I'm just trying to say that making HTML construction done via Java objects and providing convenience methods for extracting request parameters is no replacement for MVC in a general case. Say, I want to change the look and feel of my web site (an old example...), do I need to rewrite all my classes that inherit from OHTML and have them recompiled? If it's a simple project it's probably OK, but as a Java software developer I don't want to create html designs (whether or not via html directly or using OHTML classes) if there are people on the project who are good at it, and in their turn those people won't feel comfortable dealing with Java code. Again, don't get me wrong, the stuff you've created is great, but unfortunately it's not a universal MVC replacement. Just my 2 c. Vlad. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 03, 2001 4:46 PM Subject: Re: an alternative approach to the standard mvc Well that particular project you referred its just a generic construction set for Html or Xml. The toolkit I've proposed goes beyond that, my objects actually have state and are true objects in the OO sense. The toolkit does more than just abstract html construction via java manipulation, if thats what you think it does then you've missed the whole point. I welcome your comment though, cause it means I haven't explained the purposes toolkit well enough. I know what MVC is meant to do, in theory it sounds very good but one of the problems is that a lot of the times business logic drives the presentation. What I'm trying to do is make the view/model/controller a lot closer to each other, i.e. I'm trying to couple the parts that they have in common and trying to decouple the parts that should be seperated. In the normal MVC pattern you got the model, view and controller all seperated, but the reality is that there is strong relationship between all of them. Before you make another comment, please have a look at what the method updateData() tries to do and look at how you much easier you access the data from the form and how you can manipulate the presentation of the form. btw.. my solution does seperate presentation from the logic. All
