The file extention

77 views
Skip to first unread message

Phillip Krüger

unread,
Jan 14, 2018, 2:17:14 AM1/14/18
to MVC 1.0 Users Mailing List
Hi All.

I have started with a small MVC example. One of the things that I would like to question is the file extension of the view name return in the Controller:

 @Path("hello")
 public class HelloController {
 @Inject
 private Models models;
 @GET
 @Controller
 public String hello() {
 models.put("greeting", new Greeting("Hello there!"));
 return "hello.jsp";
 }
 }


This feels like I am coupling my template engine to my controller.

Would it not be possible to just return "hello" and externalize the decision on what template engine to use to another place.

So i must be able to change my view templating without changing my controllers.

Or does this means I need to write my own View Engine ?

Cheers

Ivar Grimstad

unread,
Jan 14, 2018, 8:05:27 AM1/14/18
to jsr371...@googlegroups.com
Hi Phillip,

That is correct. The default view engines for JSP and Facelets use the file extension to determine which view engine to be used. If you want other behavior than this, you will need to provide your own view engine. See JavaDoc for the ViewEngine interface listed at page 38 of the specification.

I guess we could add the possibility to configure this, but then which options should we provide? Obviously we can't cover all, so you might end up creating your own ViewEngine anyway.
The current solution with file extensions will most likely cover at least 80%, so I am not sure it is worth the effort to change this in version 1.0.

Ivar

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/25f97767-e9b2-4fba-baac-a74403102697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--

Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader

Phillip Krüger

unread,
Jan 14, 2018, 8:35:31 AM1/14/18
to MVC 1.0 Users Mailing List
Ok Great. Thanks :)

Christian Kaltepoth

unread,
Jan 18, 2018, 5:48:48 PM1/18/18
to MVC 1.0 Users
Hey all,

sorry for the delayed response, but I want to share some thoughts about this.

I basically agree with Phillip that controllers are somehow tied to the view technology, as they "choose" it when selecting the view. However, I'm not sure if this is really a problem in real world applications.

I don't think that we should include a way to externalize the decision which view engine to use on the spec level. But of course we could provide such a mechanism in the RI. That would be fine for me. If people really like this feature, we could think about adding it to the spec after the 1.0 release.

I even think that it is very simple to implement such a mechanism as some kind of "MVC extension". Basically you just have to implement a ContainerResponseFilter which checks the controller invocation result and modifies it if it doesn't contain any file extension.

Christian

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Daniel Dias Dos Santos

unread,
Jan 18, 2018, 8:57:54 PM1/18/18
to jsr371...@googlegroups.com
I found the topic interesting.

  I do not see much problem in this, I would think it legal to see the extension used when we add it in the View folder.

  besides preventing it from throwing some error / exception, as it may occur from forgetting to add the .jsp, etc.

Other than that, the way it is, in my personal opinion, is also good.

--
Daniel Dias dos Santos
Java Developer
Diretor SouJava & JCP Member
Linkedin: http://br.linkedin.com/in/danieldiassantos

Message has been deleted

Rahman USTA

unread,
Jan 23, 2018, 2:29:27 AM1/23/18
to jsr371...@googlegroups.com
+1

File extension should be configurable in MVC application.

Thanks.
Rahman

23 Oca 2018 07:56 tarihinde "Phillip Krüger" <phillip...@gmail.com> yazdı:
Hi All.
The only reason I brought it up is that both Spring MVC and VRaptor work that way out of the box.

See http://www.vraptor.org/ and https://spring.io/guides/gs/serving-web-content/

The Controllers only knows the name of the template, and the decision of what template engine to use happens somewhere else.

In a previous project where I used Spring MVC with portlets, we had many Controllers and templates, and this allowed us to start playing with other templating engines without touching the Controllers.

We also externalized the templates to outside of the deployable unit (the war file) and that allowed us to make change to the templates and template technologies without restarting the app.

We can still to this with MVC, but you will have to create your own ViewEngine.

Cheers
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.

Ivar Grimstad

unread,
Jan 26, 2018, 3:32:25 AM1/26/18
to jsr371...@googlegroups.com
Hi,

One of the advantages of Java EE over for example Spring is the zero configuration involved. I don't think we should add this layer of complexity to accommodate the 10% that are not happy with the default that is good enough for the other 90%.

At least for version 1.0. If there is a strong wish for this feature later, it can easily be added in later versions.

Ivar


--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--

Christian Kaltepoth

unread,
Jan 27, 2018, 4:44:04 AM1/27/18
to MVC 1.0 Users
Hey Phillip,

thanks a lot for explaining the reasoning behind your thoughts. I would like to make a few points regarding this.

Actually I think that having a central configuration for the "template file extension" makes it harder to experiment with other view technologies. If you want to play with the Freemarker view engine today, you can simply create a Freemarker view for a single controller and just modify the return value of the controller method to switch to the new view without touching other controllers/views. I think that completely switching view technologies is a VERY rare case and also very costly so that doing a search&replace for the template extension in the controllers would be totally acceptable.

Also, I would like to note that ViewEngines can use other strategies than checking for the file extension to see whether they are responsible for a given view name and also could embed additional configuration in the view name:
  • database:my-user-template
  • react:foobar.jsp?locale=de_DE
All this is already possible with the current ViewEngine SPI. And IMO it would be difficult to define something like "if the file extension is missing, automatically add one as configured" especially if the exact format of the view name is view engine specific.

Just my 2 cents. However, let me emphasize again that I'm absolutely fine with adding this as an Ozark specific feature to the RI. If it works good in practice and if it is used by people, we can add it to the spec later on.

Christian




To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/3d921890-f2b4-4b37-8440-743c9ff8c3d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.
--

Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Phillip Krüger

unread,
Jan 28, 2018, 9:20:48 AM1/28/18
to MVC 1.0 Users Mailing List

Hi All.

This can still be done without configuration.

I was thinking to do something like adding these two method to the ViewEngine interface:

String[] getFileExtentions();

and

String getDefaultViewFolder();

The getFileExtentions() return the extentions supported by the ViewEngine, example in JSP:

return new String[]{"jsp","jspx"};

and the getDefaultViewFolder() return the default view folder for that engine, example in JSP:

return  "/WEB-INF/jsp/";

This allows you to have a folder per ViewEngine.

The System will still load acourding to priority but also if the viewname + extention exist.

Something like that ?

Still no config needed. Out of the box all View Engines have their own folder and the controller do not include the extention when returning.

But it's not a big issue. Like we siad you can do this by creating your own View Engine.



 

On Sunday, January 14, 2018 at 9:17:14 AM UTC+2, Phillip Krüger wrote:

Christian Kaltepoth

unread,
Feb 10, 2018, 4:10:24 AM2/10/18
to MVC 1.0 Users
Hey Phillip,

sorry for the delayed response. I was on vacation and promised to stay offline for a few days. :-)

To be honest, I don't think that the methods you are proposing are a good fit. Let me explain why:
  • A method getFileExtentions() would assume that view engines use the file extension to check whether they are responsible for a view or not. But as I mentioned earlier this must not be the case. View engines could use other strategies. And there are already implementation which do so. See this view engine for an example.
  • There is already a configuration parameter to configure the default folder for view. Adding getDefaultViewFolder() would be confusing. Also, this hard coded value cannot be changed by users.
  • I don't think that a subfolder per view type is necessary and is especially weird if you are using just a single view type (as most developers will do).
However, I still think that we could implement a simple version of this requirement in Ozark without mentioning it in the spec. At least for now. If people like it, we can add it later. I'm a big fan of experimenting with such features before putting them into the spec forever.

I'm thinking of a simple configuration property like:

  properties.put(Properties.DEFAULT_VIEW_FILE_EXTENSION, "jsp");

And some simple code in Ozark like like (pseudo code):

  if( !viewName.endsWith( "." + defaultViewFileExtension) ) {
    viewName = viewName + "." + defaultViewFileExtension;
  }

Wouldn't this cover the use case you are requesting in a very simple and elegant way?

Christian




--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Ivar Grimstad

unread,
Feb 10, 2018, 5:04:56 AM2/10/18
to jsr371...@googlegroups.com
I agree,

Let's add it to the Ozark issue tracker.

Ivar

To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--

Christian Kaltepoth

unread,
Feb 11, 2018, 5:10:18 AM2/11/18
to MVC 1.0 Users
I just created an issue to track this:




To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.
--

Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users+unsubscribe@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Daniel Dias Dos Santos

unread,
Sep 27, 2018, 9:14:55 AM9/27/18
to jsr371...@googlegroups.com, Phillip Krüger

the feature that you presented, has just been made merge : 


--
Daniel Dias dos Santos
Java Developer

To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.
--

Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.

To post to this group, send email to jsr371...@googlegroups.com.

Phillip Kruger

unread,
Sep 27, 2018, 9:47:20 AM9/27/18
to Daniel Dias Dos Santos, jsr371...@googlegroups.com
This is awesome! Apologies for being so quiet on the MVC and Ozark forums, life got very busy for me...

Daniel Dias Dos Santos

unread,
Sep 27, 2018, 9:52:23 AM9/27/18
to Phillip Krüger, jsr371...@googlegroups.com
No problem, I understand.    :  )

--
Daniel Dias dos Santos
Java Developer
SouJava & JCP Member
Linkedin: http://br.linkedin.com/in/danieldiassantos

Reply all
Reply to author
Forward
0 new messages