Hi Gili,
thanks for the explanation. I understand your point with flexibility of your solution. I only see a problem when your html document would have too many fields then your html mutator code would be less readable and maintainable then if you would used any templating engine. But I do not know all your code, so please do not take this as criticism. And of course I am not “selling" our MVC support now ... I was just curios :-)
thanks
Mira
On Jun 4, 2014, at 6:13 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> Hi Miro,
>
> In my experience, Java Engineers invest too much time in theoretical benefits instead of practical ones which needlessly complicates their design and wastes time that is better used elsewhere. For example, I've seen many people using the same reasoning to separate interface from concrete class even when there was only one implementation and no possibility of 3rd-party implementations.
>
> In any case, I don't think you need a MVC framework to do what you're talking about. Here is what I do:
>
> public CompanyResource
> {
> @GET
> @Produces(MediaType.TEXT_HTML)
> public Response getAsHtml(@Context UriInfo uriInfo)
> {
> Company company = ...;
> HtmlMutator mutator = (Document document) ->
> {
> document.title(company.getName());
> document.select(".ui.breadcrumb .active.section").first().text(company.getName());
> };
> return sendHtml("html/Company.html", mutator).cacheControl(cache).variants(getVariants()).
> build();
> }
>
> @GET
> @Produces(CompanyEntities.JSON_TYPE_V1)
> public Response getAsJson(@Context Request request)
> {
> // ...
> }
> }
>
> I use @Produces to differentiate between clients requesting HTML or JSON.
> In the case of HTML, I retrieve the database record into Company. I then use JSoup to parse html/Company.html into Document and inject the company name into the <title>.
> I then send the modified HTML back to the user.
>
> Aside from JSoup, this code depends on sendHtml which consists of 10 lines of code. It has the huge advantage of leaving Java code as pure Java, and HTML code as pure HTML. There are no special tags and as a result it is easier to read and modify the code. And again, there is no MVC "framework" at play.
> <rant>
> I have nothing against libraries but I do go out of my way to minimize the number of frameworks I use. Every time I was forced to use a framework, it required me to modify my design and cost me a lot of time in the process. By contrast, libraries expose reusable functionality without imposing any design constraints on the user.
> </rant>
> Gili
>
> On 04/06/2014 5:07 AM, Miroslav Fuksa wrote:
>> Hi Gili,
>>
>> I have a question. Why do you think that using MVC when you have one view per model is a waste? When generating HTML for example I think it is good to separate html code from your model and extract functionality of HTML generation from your resource methods. This is quite convenient even if you have only one view I would say.
>>
>> thanks
>> Mira
>>
>>
>> On Jun 3, 2014, at 6:20 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>
>>> On 03/06/2014 8:05 AM, Marek Potociar wrote:
>>>> 1. Do you use server-side MVC in your projects today? If yes, how?
>>> Very loosely speaking, yes. Some of my resources return a JSON or HTML representation depending on whether the target audience (computer vs user). So yes, technically speaking I have multiple views per model.
>>>
>>>> 2. Is it a technology of the past in your opinion?
>>> Technology of the past, no. But I think it has been overhyped for many years. Most people seem to use it even when they only have one view per model (which I think is a waste). I think we are far from a point where *all* resources need multiple views and also far from the point the cost of an MVC framework outweighs its benefits. This is a fairly trivial piece of technology most people should be able to build themselves.
>>>
>>>> 3. Do you think it is worth standardizing as part of JAX-RS.next?
>>> No.
>>>
>>>> 4. Do you have any other comments/feedback on the subj.?
>>> Aim for modularity. I think only the core APIs should be bundled as part of Java EE. Anything other technology that only *some* part of the community uses should be left as an external plugin.
>>>
>>> Gili
>