I am new guy to Demandware and I am switching from Magento to Demandware.
Demandware is not opensource I am not getting proper tutorials, stuff to understand the concepts of it.
I am from Magento so I know the Magento MVC structure.
But in Demandware we have different concepts like pipelines, pipelets, ISML scripts, ECMA script, DW scripts etc.
I want to know the MVC pattern of Demandware.
How it works and what are the basic concept I need to concentrate?
I would suggest to request a Demandware XChange account as soon as possible for you, so that you get access to the Demandware community portal and also to the API documentation.
In short:
Models are Demandware Forms and Demandware API objects
Controllers are Demandware Pipelines (there are JavaScript Controllers that are recently released, you may find these easier to understand if you have Node.js experience). These can call DW Scripts (DemandwareScript is based on ECMAScript standard 5.0 for JavaScript with some extensions like E4X and optional types)
Views are the isml templates. You should avoid including a lot of logic in them, either with isml tags like isif, isloop, etc. or with isscript.
Any further questions - let me know.
Hope this helps,
Zlatin
I hope you'll be able to avoid pipelines and dwscript. Those are a bit older. The most recent version works with plain old JavaScript, with pipelines being replaced by controllers.
Be aware that the underlying JavaScript engine is Rhino, which isn't really modern.
The Demandware documentation is open source now anyone can access to without having an exchange account it has the latest SFRA(javascript) based concepts as well
here is the link for the docs
Demadware Documentation
Demandware is very much designed around the MVC concept (in theory). The pipelines are basically your controllers and each pipeline filename (the xml file) is the first part of the URL and the start nodes inside the pipeline are the second part of the URL that basically represent the controller (eg Cart.xml has a start node called Show, so the url is Cart-Show). At the end of the pipeline flow chart is, usually, an interaction node to that links to an ISML file, those are basically the View and are HTML with some minor Demandware-specific markup.
Typically in the MVC world you try to prevent putting business logic in the views, however if you use SiteGenesis as your starting point you'll find that not to be the case on most of the pages. If you switch to using Javascript Controllers instead of Pipelines, then it'll be closer to the Magento style of MVC (but using NodeJS-like syntax).
I am using Spring 4 MVC to display serve my web page. I now want to display the same content with different layouts wrapped around the body/content depending on the current HttpServletRequest (e.g. request.getServerName()). This means https://page1.test/page.html will be mapped to the same controller as https://page2.test/page.html and returns the same content depending on the controller logic, but page1.test draws for example a different header and footer.
As far as I know, Spring MVC is not capable of doing this. I am now planing to use Apache Tiles 3 or JSP 2.0 tags to do this. Is there any best practice and how can I do this (Spring Java Config is preferred)?
You should take a read of http://tech.finn.no/2012/07/25/the-ultimate-view-tiles-3/ just to see how far you can push Tiles-3
Indeed it can solve what you're after.
(That blog website has just been migrated from wordpress to github pages so some of the code snippets require horizontal scrolling, we're still cleaning these small formatting issues up so please excuse them)
We have to implement multiple-document-interface web application. Each document has to live in a separate tab (but on the same page, it has to be SPA). There may be up to 50 opened tabs simultaneously and application should give ability to group tab panes by modules.
One of our options were to use AngularJS for this task. We like the way Angular handles partial views, structures application by using modules/controllers and performs dependency injection.
After digging in for couple of days, we've figured out that there may be some problems with the way bindings work: there is no easy way to prevent angular from watching tabs, which contents are not currently displayed to the user. You can imagine situation when user will have around 20 opened tabs and this whole thing becomes slow as hell! Also our application is very grid-heavy, so for grids I think we should avoid ng bindings at all.
We were thinking about ng-view and the way it recreates DOM on each activation ... this looks overkill and will force us to put all UI state into the view-models, even for scroll-bars :)
Can you suggest some possible ways to improve performance with Angular and MDI? Maybe we should even consider using some other ui-framework/set of tools to achieve same results?
What's important:
modularity (AMD)
dependency injection
declarative bindings (we do like how angular and knockout solved those problems)
MVVM/MVC
ability to create multiple instances of the same controller (open multiple "details" tabs for each specific item from the grid, for example)
modularity - Angular has it's own modularity rules/patterns which are good if you want to conform to them, but if you want to make something modular in a different way, eg... allow forms to be self contained so that multiple instances of them can dynamically be opened concurrently it's quite difficult
dependency injection - Angular allows you to write code that you can inject other into, but you cannot inject Angular, it seems an oversight that you cannot test your code isolated from Angulars?
declarative bindings - yep, the way Angular binds literals within HTML with the JS code makes it really hard to create MDIs with multiple concurrent instances of a single form. You really need to dynamically create your form instances with their own identifiers (in addition to Angulars) then scope your own identifiers within the bounds of a shared set of JS files (which is what you want), however then Angular's binding will get in the way of each instance if you continue to use Angular's bindings - alternatively you can try modify the HTML dynamically get Angular to refresh it's bindings.
Basically anything to do with MDI is harder than it needs to be with Angular and it's worth looking at alternatives for such projects before hand.
AngularJS can indeed be heavy on a big application, but only when you make a change inside the $scope. The bigger part of this time is spent looking for modification by dirty checking.
If you keep an AngularJS application inside a non active tab, a dirty checking can only happen after a outside event (like a WebSocket message). You can optimize your application to remove those listener when the tab is not focused.
If you follow the best practice of AngularJS, performance issues with a lot of pages opened should not be a problem. The bigger performance problem of AngularJS come with very big amount of data inside its $scope, but there is a lot of solutions proposed all over the internet.
I have to decide on the view layer technology to use with Spring MVC 3 and I came across Thymeleaf.
Has anybody worked with Thymeleaf or has any experience with it. What will I gain and miss if I happen to choose it to work with Spring 3.
I wanted my front end designers to feel comfortable was why I was thinking if I could use thymeleaf with Spring 3 and still have all the functionalities we get with JSPs + Spring MVC 3.
Thymeleaf and Spring are a very nice match. The spring integration of Thymeleaf is done as it's supposed to be and it was nicely documented how to get started.
I use this combination since one year in several projects and I'm still happy with the choice I've made at the time.
Thymeleaf propagates the so called "Natural templating", which means that the templates can be viewed without the template engine, they are html files with additional tag attributes which browsers just ignore.
This means that a webdesigner can design the page, hand it over to the developer and get back again if changes to the layout have to be made.
While I liked this idea a lot in the beginning, I soon realized that, as developers, we tend to create components to be reused. This results often in templates having either not alot to display or also an extreme amount of elements.
Imagine some switch statement in a table cell component which renders either checkbox, textfield, select box, and so on. The table template including this cell fragment does not resolve it without an engine. Or imagine the header fragment with all the style and js declarations. Css will not be available in plain file mode.
But you can add additional html tags and remove them during processing. So natural templating is still possible. Just a lot to write :)
There are support extensions around solving this issues (using JS to pull in the fragments for example) but I havent used them as my applications are normally deployed within 30sec and I'm even able to change the templates on the fly without a redeploy.
After you also have a quite nice eco system around thymeleaf. The ability to extend Thymeleaf is done in a way I really enjoy! (Having written two smaller extensions myself).
I prefer the layout dialect instead of the include approach. That's a matter of taste i would say.
Choosing Thymeleaf over Plain JSP is clearly favorable from my point of view. Take a look at the webpage and decide for yourself ;)
I'm working with Spring 3 and Thymeleaf for a year and think it's a good choice. I came from Grails and Play and look for a good alternative and created FuWeSta. You can look at the rudimetar sample-app.
I was reading about JSF that it's a UI framework and provides some UI components. But how is it better or different from number of components that are available from jQueryUI, AngularJS, React, Vue.js, Svelte, ExtJS, or even plain HTML, CSS and JavaScript.
Why should someone learn JSF?
JSF to plain JSP/Servlet/HTML/CSS/JS is like as jQuery to plain JS: do more with less code. To take PrimeFaces (jQuery + jQuery UI based) as an example, browse through its showcase to see complete code examples. BootsFaces (jQuery + Bootstrap UI based) has also a showcase with complete code examples. If you study those examples closely, then you'll see that you basically need a simple Javabean class as model and a XHTML file as view.
Note that you should not see JSF as replacement of alone HTML/CSS/JS, you should also take the server side part into account (specifically: JSP/Servlet). JSF removes the need of all the boilerplate of gathering HTTP request parameters, converting/validating them, updating the model values, executing the right Java method to do the business stuff and generating the HTML/CSS/JS boilerplate code. With JSF you basically end up with a XHTML page as view definition and a Javabean class as model definition. This greatly speeds up development.
As with every component based web MVC framework, you have in JSF less fine-grained control over the rendered HTML/CSS/JS. Adding custom JS code isn't that easy as you have to take the JSF view state in the server side into account as well (e.g. enabling a disabled button in JS side won't enable the button in JSF side, which is in turn a huge security advantage). If that is however a major showstopper, then rather look for an action based web MVC framework like Spring MVC. You'll only take into account that you have to write all that HTML/CSS/JS code (and prevention against XSS, CSRF and DOM-manipulation!) yourself. Also if you fall back from Facelets to JSP, you'll miss advanced templating capabilities as well.
On the other hand, if you have a big JSP/Servlet/HTML/CSS/JS/jQuery based website and you'd like to refactor the repeated JSP/Servlet/HTML/CSS/JS/jQuery boilerplate code into reusable components, then one of the solutions would be JSF. Custom templates, tagfiles and components can aid in this. In that perspective, JSF stands above JSP/Servlet/HTML/CSS/JS/jQuery (and that's also why it's pretty important to understand those basics before diving into JSF).
You can find a real world kickoff JSF based project here: Java EE Kickoff App. You'll see that it contains next to JSF as good HTML5, CSS3 and jQuery.
See also:
Difference between Request MVC and Component MVC
Difference between JSP, Servlet and JSF
What are the main disadvantages of JSF 2.0?
Is it possible to use JSF+Facelets with HTML 4/5?
When to use <ui:include>, tag files, composite components and/or custom components?
JSF was created to make it so that java shops didn't have to learn stuff like jQuery and build complex JS but instead focus on a purely Java stack. In a world where time is money and lots of places already focusing on Java development, one less language/piece in the stack makes training and maintaining faster and thus cheaper.
I'll add that JavaScript is easy to become a maintenance nightmare on large teams, especially if some of the developers on the project are not highly web savvy.
With Javascript and frameworks such as jQuery you have full flexibility and full control . With ext's etc you lose much control and must adapt to the framework. With JSF you totally lose control and must totally adapt to the framework. You're invoked in lifecycles etc. and finally you have no control when the call to the server can be made and where not. If you are to do something considered 'special', you're in very hard position. And in JSF world even such basic things as multicolumn table sort or fields where you can type only limited set of characters (such as number field) are considered 'special'.
However, the more flexibility you have, the more errors or bad practices you can made. High flexibility works only with highly intelligent programmers, others will turn the project into unmanagable nightmare.
But, with JSF and its limited flexibility, there's always only a few (or even only one) correct way to do something. You are very limited, you can't make shortcuts, you must write more XML etc. - but when adapting to standard, there's better control on the code the unexperienced or low-skilled programmers will produce. As a result, big corporations love JSF because it is 'safer' for them.
When I moved from GWT to JSF, I was shocked, how many things, that was natural to me, was considered highly untypical and how much simple things were so hard to achieve. What's more, even making the smallest changes, such as adding ':' sign after label, which in GWT/jQuery powered app would be changing one function generating label, required changing dozens of files with localized properties, which wasn't even considered by anyone except me strange...
The benefits of using JSF are not only in generating xhtml + css + js. Sometimes JSF imposes a restriction on the markup you can generate, like any component based framework. But JSF is not just for that, its lifecyle helps greately. After validating the input it can update the model and sync your server side beans without any effort. you just say "whatever the user types here, check if it's a number, if yes then store it in the property YY in object XX" and JSF will do all that.
So yes, you can still use JQuery, JS, etc. But JSF provides many benefits when it comes to writing server side code and saves you from a lot of boiler plate.
I strongly disagree that jsf adds anything. It only adds overhead. Doing ui stuff on the server is the most ridiculous thing ive ever heard. And javascript on large teams works great - its called reusing code.
Just wrap the jquery in some jsp tags, thats all you need and youre done, and dont endure the.shackles and scalability issues with.jsf and richfaces.
Having worked with JSF, Spring MVC, Struts, Grails, JQuery, and ExtJS my opinion is that Grails + ExtJS is one powerful combination.
I would pick Grails over JSF any day. I like the completeness of ExtJS as the client side framework and library, but it comes with a steeper learning curve than JQuery.
Here are the biggest differences between jQuery & JSF:
no MVC architecture
no state control (store date in session or conversation, auto-clean up, etc.)
no (default) validation library
no templating library
no advanced navigation/routing
client side
jQuery was never intended to be used as a full stack webframework. It was more intended for replacing low-level JS code so that writing JS becomes easier and more powerfull in less lines of code.
And it should thus mostly be used to add behaviour on HTML elements.
Having used ExtJS framework for a large web application, I know how easy it is to use. The ExtJS (Schena) is best suited for (Oracle 11g) database interactions in MVC architecture. The View was for the visual / user interactions. The controller specified the 'processing' and the triggers that needed to be used form the PLSQL packages (the API for the CRUD, SQL select queries etc.). The Model and the store files were used to 'map' the data items to the Viewer / inputs.
ExtJS is not suitable for non database intensive web interfaces - where Angular JS may be a better fit.