I have created a spring application with multiple language support, using spring localization/Internationalization and jstl. Now I am going to remove all the jsp and replace it with html. Can make use of spring localization/Internationalization and resource bundles in pure html without jstl? (I am sure there has to be a way.)
You can get rid of JSTL if that's what you are asking for. After all, Spring has its own <sp:message> tag.
However, if you want to get rid of JSP completely and only serve static HTML, I am afraid it can't be done correctly.
That is, you can possibly generate the whole page with JavaScript (i.e. jQuery), but how useful is that?
And you'll be forced to implement some means of Localization for JavaScript anyway. I mean you'll probably need to generate file with translations on-the-fly.
It's do-able, but it would be extremely easy to introduce for example concatenation defects (that won't allow for re-ordering the sentence, that is proper translations).
To summarize this: you probably can do that, but you probably should not.
It is possible..with minimum tweaks..
Dont remove jSP,JSTL etc..
Convert each submit request to ajax..A server doesnt care whether a request is a normal browser submit request or XMLHttpRequest(ajax)..server will use JSP,JSTL to prepare appropriate HTML..u need ajax to render that html string into DOM.
$.ajax(url:'/xyz',
success:function(htmlFromServer){
document.open();
document.write(htmlFromServer);
document.close();
});
Related
I'm trying to make my CSP without unsafe inline.
Since I have to manually check every file from every app, I may as well move the scripts to external files instead of creating a million word CSP entry in the web.config by adding hashes or nounces.
This seems easy enough for client side content, but many templates have razor code in then such as:
<script>
alert(#myVar);
</script>
How can I move this to external?
So in general if you JS needs some input parameters you must of course put them somewhere, and only the razor will know what they are.
The simplest way is still to just have the initial call use the variables - like in your example above. If you have security concerns, doing type-checking in razor should eliminate that for you.
For example, if you do #((int)thing.property) than it simply cannot inject any unexpected payload.
If for some reason you really, really don't want this you can use a attribute-json convention, like
<div class="myGallery" init='{"files": 17}'> gallery contents </div>
and pick it up from the js you created. but this is quite a bit of work, so I would recommend the simpler way.
I am running a springboot application with Thymeleaf and reactJS. All the HTML text are read from message.properties by using th:text in the pages, but when I have th:text in reactJS HTML block, reactJS seems angry about it.
render() {
return (
<input type="text" th:text="#{home.welcome}">
)
}
The error is:
Namespace tags are not supported. ReactJSX is not XML.
Is there a walkaround besides using dangerouslySetInnerHTML?
Thank you!
There is no sane workaround.
You are getting this error because Thymeleaf outputs XML, and JSX parsers do not parse XML.
You did this because JSX looks very, very similar to XML. But they are very, very different, and even if you somehow hacked Thymeleaf to strip namespaced attributes and managed to get a component to render, it would be merely a fleeting moment of duct-taped-together, jury-rigged code that will fall apart under further use.
This is a really, really bad idea because JSX is Javascript. You are generating Javascript on the fly. Just to name a few reasons this will not work in the long term:
This makes your components difficult if not impossible to test.
Reasoning about application state will be a nightmare as you will struggle to figure out if the source of a certain state is coming from Thymeleaf or JS.
Your application will completely grind to a halt if Thymeleaf outputs bad JS.
These problems will all get worse with time (Thyme?) as as developers abuse the ease with which they can render server-side data to the client-side, leading to an insane application architecture.
Do not do this. Just use Thymeleaf, or just use React.
Sample Alternative: I primarily work on a React application backed by a Java backend. So I understand how someone could stumble upon this hybrid and think it might be a good idea. You are likely already using Thymeleaf and are trying to figure out how you can avoid rewriting your servlets but still get the power of React.
We were in a similar boat two years ago, except with an aging JSP frontend, but the difference is negligible. What we did (and it works well) is use a JSP page to bootstrap the entire React application. There is now one JSP page that we render to the user. This JSP page outputs JSON into a single <script> tag that contains some initial startup data that we would otherwise have to fetch immediately. This contains resources, properties, and just plain data.
We then output another <script> that points to the location of a compiled JS module containing the entire standalone React application. This application loads the JSON data once when it starts up and then makes backend calls for the rest. In some places, we have to use JSP for these, which is less than ideal but still better than your solution. What we do is have the JSP pages output a single attribute containing JSON. In this way (and with some careful pruning by our XHR library) we get a poor man's data interchange layer built atop a JSP framework we don't have time to change.
It is definitely not ideal, but it works well and we have benefited vastly from the many advantages of React. When we do have issues with this peculiar implementation, they are easy to isolate and resolve.
It is possible wrap ReactJS apps in Thymeleaf. Think if you want a static persistent part (like some links, or even just displayed data), you could use Thymeleaf. If you have a complicated part (something that requires DOM repaints, shared data, updates from UI/Sockets/whatever), you could use React.
If you need to pass state you could use Redux/other methods.
You could have your backend send data via a rest API to the React part and just render your simple parts as fragments or as whole chunks of plain HTML using Thymeleaf.
Remember, Thymeleaf is really just HTML. React is virtual DOM that renders as HTML. It's actually fairly easy to migrate one to the other. So you could write anything "Static" or that does not respond much to UI, in Thymeleaf/HTML. You could also just render those parts in React too, but without State.
Thymeleaf 3 allows you to render variables from your Java to a separate JS file. So that is also an option to pass into JSX
function showCode() {
var code = /*[[${code}]]*/ '12345';
document.getElementById('code').innerHTML = code;
}
Now you can use data- prefix attributes (ex. data-th-text="${message}").
https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#support-for-html5-friendly-attribute-and-element-names
I am volunteering on a website-based project that is trying to make all pages fully operable JavaScript free before adding any JavaScript for enhancements, and I was asked to investigate whether or not a particular scenario could be handled purely through HTML/CSS.
What we have is a form that is populated to help us filter a list of tickets that are displayed on the screen after a page update through a GET action, which itself works fine, but the concern with the current implementation is that the URL cannot be made into a permanent link. The request, however, to keep the permanent link as minimal as possible, is to only send GET parameters for fields that are populated with something (so, suppressing GET parameters for fields that are blank) instead of having a different GET parameter for each form field on the page.
I have thought of several ways that could be done, most including JavaScript (example: create fields with ids but no names and a hidden field w/ name that uses JS to grab the data from the fields), but also one that would be a POST action with a redirect back to the GET with a human readable string that could be permanently used. The lead dev, however would prefer not to go through the POST/redirect method if at all possible.
That being said, I'm trying to make sure I cover all my bases and ask experts their thoughts on this before I strongly push for the POST/redirect solution: Is there a way using only HTML & CSS to directly suppress GET parameters of a form for fields that are blank without using a POST/redirect?
No, suppressing fields from being submitted in an HTML form with method of "GET" is not possible without using JavaScript, or instead submitting the form with a POST method and using a server side function to minimize the form.
What fields are submitted are defined by the HTML specification and HTML and CSS alone cannot modify this behavior and still have the browser be compliant with the standards.
No, you cannot programmatically suppress any default browser behavior without using some kind of client scripting language, like JavaScript.
As a side note, you say "JavaScript for enhancements", but JavaScript is not used for enhancements these days. And no one in the real world would except a decent front-end without the use of JavaScript. I would suggest you simply use JavaScript.
I do not think you can avoid Javascript here to pre process before submission to eliminate unchanged /empty form fields.
I am debating on what to I should learn to accomplish this. Mainly If I take a bunch of info from a database to load on a page what is the best way to manipulate the page and not have to reload. Is the best thing to use something like XML or is there something else I should use. I know a lot of this uses HTML Dom and XML Dom, but I dont want to start learning one yet that I dont need.
The name of the technique you are looking for is AJAX, which stands for Asynchronous Javascript and XML (although most AJAX these days uses JSON [JavaScript Object Notation] instead of XML).
AJAX requires working knowledge of JS and the DOM. Look at jQuery as a library that makes AJAX and DOM manipulation easy.
How it fits together:
Javascript makes asynchronous requests to your server (without refreshing the page) that return the required data. When the request completes, the JS then inserts that data into the DOM
Using jQuery simplifies this process:
$('#data-container-id').load("my-data.html",{get:"data"})
will fetch "my-data.html?get=data" and put the returned html into a div with the id "data-container-id"
What's the best way to create printable letters from an MVC application? I'm looking for sort of a mail merge thing from my app that prints a form letter with various values filled in.
In ASP.NET, I previously did this by creating an HTML document and displaying it as application/msword, but I did that with code-behind, which isn't an (easy) option in MVC, and I don't know if that's the best method or not.
Note that this is an internal application, so it can be assumed everyone has Word on their computer. With that said, it would be nice to bypass Word, but I could go either way. The simpler the better. Any ideas/methods welcome.
Since this is just HTML with the ContentType set to application/msword I can't see any reason why you would want to use code-behind.
A standard MVC view with a typical HTML template peppered with appropriate <%=...> where view data needs to be inserted would seem to be the sensible approach. Even where you might want to loop.
BTW, why isn't code-behind an easy option?
In your controller:
return Content(contentGoesHere, "application/msword");