Front Man 1.5.0

[Michael Malamud]

Ok, so that makes a lot more sense.

So if I am using FrontMan, do I even need a REST framework such as Restlet?

And when does FrontMan 2.0 release?



Thanks again,
Mike

[Bear Bibeault]

I'm not sure that you need both. If you are going to be targeting RESTful URLs exclusively, it might make more sense to go with a RESTful framework. If it's just a few URLs then sticking with FrontMan might be fine.

There's no firm date for FrontMan 2 yet. The ecosystem for web apps has been in quite a state of flux (the emphasis on RESTful being a good example) so there're a lot of changes I'd like to make to FrontMan 2 to keep up.

A beta of FrontMan 2 is available, but be aware that it might change quite a bit once I get some free time to work on it.

[Michael Malamud]

I guess I need to figure out whether I can be targeting RESTful URLs exclusively. Right now I think the only time I wouldn't need to target a RESTful URL is
when a user clicks a link to load a new page.

I chose FrontMan because I thought (not sure I still don't) I needed a server-side MVC framework. I like the concept of a front controller that dispatches control
accordingly and am/was using scriptless-JSP (aided by JSTL and JSP tag files) to present the content to the screen. It all flows very nicely.

But now as I investigate the front end and the more it seems like this is going to be a JavaScript intensive web app, where most of the coding will be on the client-side,
I am starting to rethink some earlier decisions.

Instead of loading content from the server-side, I am thinking I will load a jQuery-based UI widget and then issue an AJAX request to gather the data to populate that
widget. I'm a newbie to REST, but this model seems to fit nicely with REST-based solutions.

What are your thoughts on relying more heavily on the client-side (via JavaScript) to do most of the heavy lifting.

And would you say given recent trends in web application development, that RESTful solutions are starting to push MVC solutions aside?

I would also like to say that I appreciate your feedback on my questions today. Feedback from you goes a long way in my book as you are a very respected developer,
author and contributor to software engineering.


Thanks,
Mike

[Bear Bibeault]

Michael Malamud wrote:Instead of loading content from the server-side, I am thinking I will load a jQuery-based UI widget and then issue an AJAX request to gather the data to populate that widget. I'm a newbie to REST, but this model seems to fit nicely with REST-based solutions.

That is not an unviable approach. It's one that I've yet to embrace myself, but I know of a number of web apps (no, none that are generally available) that were engineered that way.

What are your thoughts on relying more heavily on the client-side (via JavaScript) to do most of the heavy lifting.

I think it has merit, but there are some drawbacks and obstacles. You'll end up with some middleware on the client -- no way about it. It's also challenging to use a purely RESTful API, as pure REST knows zilch about forms. It wants its representation format (XML or, my preference, JSON) as the body of the PUTs. You also lock yourself out of some of the web audience -- those using older browsers and those who disable JavaScript.

And would you say given recent trends in web application development, that RESTful solutions are starting to push MVC solutions aside?

No. Proper structuring of apps should be here to stay. Even RESTful APIs, with no or limited "V", benefit from Separation of Concerns.

Feedback from you goes a long way in my book as you are a very respected developer,author and contributor to software engineering.

Thanks for the compliment. I try to be a good contributor -- I just wish that I had more time to do so.

[Michael Malamud]

Bear,

Would it make sense to do something like the following:

Have all requests for pages (non REST requests) work as usual in that they continue to come in through

http://www.myapp.com/myApp/command/*


And then for REST requests have another mapping in my web.xml file that maps REST calls differently?

<servlet>
	<servlet-name>jersey</servlet-name>
	<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
	<init-param>
		<param-name>com.sun.jersey.config.property.packages</param-name>
		<param-value>com.theserverlabs.test.rest</param-value>
	</init-param>
</servlet>

<servlet-mapping>
	<servlet-name>jersey</servlet-name>
	<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

Therefore any requests coming in to

http://www.myapp.com/myApp/rest/*

would be handling separately.


Does this many any sense?


Thanks,
Mike

[Michael Malamud]

Or.......

If I want to issue a REST request to FrontMan do I instead do it like this:


http://www.myapp.com/myApp/command/REST/*


Using "REST" as the verb to tell the front controller that this is a Rest request and it should be handled as such?

Trying to work through this and was wondering if this solution made sense.



Thanks,
Mike

[Michael Malamud]

Does this have any merit?

[Raghavan Muthu]

Michael Malamud wrote:Does this have any merit?

Of course, Yes!. Otherwise these many people would NOT have been talking about this.

First start using this and then you would understand and agree Beforehand you should have got a good experience in with normal Servlet programming with other controller based action frameworks. Then you would appreciate the merits of this.

[Michael Malamud]

I think you have misinterpreted my question.

I agree that FrontMan is very good.

What I am asking about is my suggestion for using it to handle RESTful web service requests.

See a few posts above...

[Bear Bibeault]

It's possible to do it either way. Jersey is well-suited to dealing with RESTful requests, so using is side-by-side with FrontMan may be your best bet. In addition to path info parsing, Jersey will do marshaling of complex parameters and content, and dealing with requests based upon HTTP methods.

Also, I'd avoid uppercase characters in your mappings.

[Michael Malamud]

So RESTful requests would not come into the FrontMan front controller?

Instead they will be processed by Jersey?

[Michael Malamud]

Using commandContext.forwardToView("myView")

How do I pass along query string paramters to the view?