I am starting a large scale EXT JS application and wanted to know if anyone knows of any helpful resources. Everything i've seen up to this point has been a single page application. I would like to use MVC for the front end. Thanks for your help!
#Sra's comment is the most appropriate response here.
Regarding 'single page applications' then can certainly be used for larger scale projects, but careful management of code and the DOM is needed.
I think you might need to provide a bit more information about how you're planning to do things and what you're worried about.
Ext offers a client side MVC implementation but this does tend to centre around the single page application model. What this means is that you write your models, views and controllers and let your app decide which to render.
The app is responsible for creating and disposing of client side controller and view instances, and the models really just exist to validate data and provide a sensible mechanism for sending / retrieving data from the server side.
If you're wanting to use a typical server side MVC implementation e.g. ASP.NET MVC, then it should be noted that unless the app is massive, you'll probably just end up with a single .NET 'view', this view will contain your entire ExtJS app.
You 'can' if you want, create a series of mini apps via Ext and render those in several server side views, but you will end up with a lot of duplicated (or shared) code which may well be a pain to manage.
So to sum up, yes, you can use Ext for larger applications, yes you can use MVC (both client and server side) and finally yes, your front end will likely form a single page application.
Just to add a bit to the #dougajmcdonald's excellent answer: there are improvements to MVC architecture and dependency handling coming up in Ext JS 4.2, that are specifically aimed at folks with big apps on their hands. It will be a lot easier to share code between related applications, which would also make writing multi-page apps easier as well.
EXTjs is not supposed to be coded in single page. EXTjs 4 supports MVC architecture.
http://docs.sencha.com/ext-js/4-1/#!/guide/application_architecture
please sencha command also. it helps you to create a backbone of MVC application
http://docs.sencha.com/ext-js/4-1/#!/guide/command
Related
We are planning to migrate the UI of an application from XHTML based legacy JSF (1.X) based framework.
We are not going to change everything at once but would, migrate one of the several tabs in ReactJS and keep rest of the pages as it is in XHTML to see how it goes.
I have been trying to find a way to do this but no luck yet. Can anyone give some hint to go ahead with this ?
Thanks in Advance
my Suggestion:
-is to split your pages/tabs using any microfrontend approaches example (iframe, web component )
remove any jsf session dependencies and depend on URL query params (keep only one entry point for your splited app)
apply sso token ,
go ahead with your changes safely without impacting other parts
You would want to prevent coupling between your legacy JSF application and your React components. You could achieve this by making your React-based parts as independent as possible (as with microservices).
Be wary of state managed in application-/session-scoped beans.
Don't depend on stuff that you would rather throw away but can't do at the
moment. Your legacy application is probably too coupled and
monolithic anyway.
Keep in mind that you will (should?) throw away your legacy code eventually.
Keep things clean and fresh for young developers (My experience is, that JSF scares them away - rightly so). This should get yourself a nice and quick developer feedback loop without the need for some heavy build process with legthy container deployments.
Integrate your old and new application using some sort of SSO-like authentication and make your styling seamless.
If you are using Primefaces as a component library, you can also also benefit from their React components, which are not quite on par with the JSF equivalents, but they give you a starting point to get your look-and-feel right. But then again you establish new, somewhat unobvious coupling with your legacy application. Be careful here.
I want to implement Sitecore application (single page design with angular js) :
Is that possible ?
If it is possible, what about experience editor, it will work with it ?
What about Sitecore personalization ?
I have no experience with angular js. what should I take in my consideration to achieve this
I will use Sitecore 8. i found this helpful blog about that but as he mentioned, page editor simply won't work
Thanks.
1.
Yes it is possible, I implemented a SPA in Sitecore 7 using AngularJS for the front-end and WebAPI to serve the data from Sitecore Items and it all worked really well together.
You could look into using Sitecore MVC Controllers which will work just as well as WebAPI. Or if you have time to learn a new Sitecore Technology you can look into using Sitecore's Entity Service. Either will work for serving data from Sitecore.
From experience I recommend you make controllers which are responsible for a single type of data consumed by the AnglarJS. The models passed by the controllers should be lean, containing only data relevant to the controllers purpose.
2.
For my implementation, the Experience Editor would not work as I used AngularJS to manipulate and present the data. It could be possible to use Sitecore Controls if you don't pull out the data using AngularJS but I don't think it'll be possible without hacking at it with code.
3.
Personalisation through the Experience Editor should be possible if you use Sitecore Controls. Personalisation through the Content Editor and code will be possible. I recommend you build your SPA as you would most Sitecore implementations; Layout, Sublayout etc. You can implement personalisation through code in the Controllers, Application Logic etc
4.
I had no experience with AngularJs either but I learned everything I needed to know from tutorials and the rest is logical enough for you to figure out if you're familiar with any programming language. I recommend you work through this Codecademy Tutorial that has you completing exercises - its how I learned.
I've yet to write a blog on how I achieved it but Dave Peterson has written two blogs on his experiences with SPA with Sitecore and AngularJs that might be worth a read.
Yes it is possible
Yes you can use the experience editor, BUT you have to build the site in a specific way. Not in the "normal" way.
Again, same as experience editor, you can use it, but the site has to be built to accommodate that.
Not sure on Angular - I have used backbone, but the principles are very similar.
I have a blog post on how we achieved this for a client: http://www.sitecorenutsbolts.net/2015/12/07/Single-Page-Applications-in-Sitecore-Part-I/
Have a read of that, it gives the principles you should follow to enable Sitecore in an SPA.
Anything is possible in Sitecore, but some customization are too complex to be considered practical.
You can easily build SPA application with the following limitations:
Display various views with either
a) server generated templates, or
b) static .html template with Sitecore-managed content (retrieved as json via custom controllers or Content API) and bound to template using AngularJS.
Limit the scope of personalization to just content.
Have experience or page editor view significantly different from the end-user experience. And even then, this will require separate design to create and maintain.
What is significantly more challenging is:
Utilize Personalization to dynamically display different renderings. Hide/show renderings, etc.
Have Experience Editor reflect the actual design of the SPA experience
I am building an admin panel that involves mostly CRUD operations in AngularJS. I have seen many examples of how to do this on the web. Each example I have seen is a single page application that handles a single type (for example Person, Employee, etc.).
My question is the following: If the admin application I am building will involve a large number of CRUDS (one for each type used in the database), should I still use one single page app for the entire admin panel website or should I make each CRUD a separate single page application?
What is the best practice for this?
We've chosen to use a single app for a multi-model admin GUI built with angular.js called ng-admin (open-source, see code at https://github.com/marmelab/ng-admin).
It works very well, and it's easier to deal with model relationships (one-to-many, many-to-one, many-to-many). Doing so with several apps would imply booting several applications - probably bad for webperf.
Angular is really good for CRUD operations. There are many large scale apps with lots of CRUD operations that have used angular. Go to built with angular and see the apps. You can find the source code as well.
Generally, rest services are used to make CRUD apps.
In my opinion, making each CRUD a separate app would not bring out the best performance of a SPA as some contents like the header and footer do not change much, so it would not be feasible to render them multiple times.
Is it good practice to combine MVVM [angularjs,knockout.js]with MVC [JSF/spring].
Is it good way to control mvvm object/variables/ from inside JSF page.
Lets say I have to update a dropdown list in angularjs model by using jsf controller to fetch list object and update angularjs dropdown model. Is this a clean way or a junk way or is it just a work around.
I have to admit that I don't really know JSF or Knockout. However, I can easily imagine that because both sides want to be in charge of viewed components, a component based framework like JSF or Wicket might have trouble playing together with Angular. A couple things come to mind:
Why do you need the component framework from the server side? Why not use a request-based framework like Spring MVC or struts? They should work fine as they are just taking care of the overall page loading.
You will probably be ok if you decide to use one technology to do one thing. For example, do your page containers with JSF, and everything inside the page with Angular. I think you'll be ok with that. Of course, you are losing a big part of the benefit of JSF.
I'm actually doing this right now. I can't say what the best practice is, but we found that we needed to be able to output dynamic HTML from the server, even if you have an MVVM framework in the front end. Things like internationalization is better handled on the server side, and with purely static HTML from the server you run into a lot of limitations.
The main drawback is complexity. You will have controllers, models and views on the server, combined with controllers, templates and viewmodels on the client. This makes the architecture a bit confusing, especially as you bring new members into the team, so documentation and code structure becomes very important.
Overall, I think it's a valid approach. It hasnt bitten us yet, at least :)
Does it make sense having a solution that uses both Freemarker and AngularJS?
I tried to convince everyone on my team of switching to Angular, and a more experienced developer than me pointed out that he prefers server-side rendering, which is both arguable and valid. But then he told me that if I still want to use Angular just use it with Freemarker instead of replacing it.
I'm a junior programmer, as far as I can understand they are designed to the same purpose.
It depends on the needs.
For example, if you want to break your page into individual re-usable components that you can tie based on some logic on the server side, then using freemarker or velocity for building these components makes sense.
The freemarker or velocity templates might in-turn use angularJS components that would be rendered on the browser and evaluated on the client side.
The server side templating would give you the ability to design re-usable angular components.
Now, some may try to use the Object component in HTML5 for doing the same thing, but this is not recommended as using Object expects a fully formed HTML element with its own <html> opening and closing tag.
Not something that is intended for a small reusable component.
As an example consider having your page header and footer in its own html template file that you would like to tie in for all the pages in your application.
As I google for Freemarker i realize it is just a templating engine. AngularJS is not a templating engine. Templating engine is just part within this framework. So both of them cannot be compared.
AngularJS is a full fledged framework for creating Single Page Applications (SPA). So if you want just templating capabilities on client side, i suggest you better look for some other light weight libraries.
If you want to use AngularJS you need to decide
Whether you can structure your app as a SPA
Does the site needs to be SEO optimized. Which has limited support in Angular or as a matter of fact in any client side framework.
Ready to use the AngularJS templating engine because it is awesome with its support for oneway\two way active bindings. If you don't use it templating engine you are loosing a lot.
No it clearly does not make sense as they serve very different purposes. All I can think of is that you either misunderstood the more experienced developer or he really has not understood the business case (WHY something is worth using) of using either technology. In my experience as a j2ee developer, I find that many server side developers (experienced or not) may not be too educated on the many new advances recently made in client side development. With Angular you are not limited to SPA. You need an insight into the overall architecture of your current project to determine if its a good fit. There are ways around the SEO issues or you can purchase an SEO solution. But clearly not a best choice if SEO is essential.
Unless it is a team decision and there are clear problems Angular solves for you, I would not suggest getting stuck alone with a new technology that only you know. Keep it as a hobby and when you really understand the best practices and benefits you can then try being an evangelist.