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.
Related
I'm new at programming. I want to know how to use my database with react? I can create db and tables with PostgreSql but how to connect from react project? Do we have any guide/tutorial available? I found node-postgres. Is that useful or should I find another thing?
Frontend and Backend are the two most popular terms used in web development. These terms are very crucial for web development but are quite different from each other. Each side needs to communicate and operate effectively with the other as a single unit to improve the website’s functionality.
BackEnd
Backend is server-side of the website. It stores and arranges data, and also makes sure everything on the client-side of the website works fine. It is the part of the website that you cannot see and interact with. It is the portion of software that does not come in direct contact with the users. The parts and characteristics developed by backend designers are indirectly accessed by users through a front-end application. Activities, like writing APIs, creating libraries, and working with system components without user interfaces or even systems of scientific programming, are also included in the backend.
FrontEnd
The part of a website that the user interacts with directly is termed as the front end. It is also referred to as the ‘client-side’ of the application. It includes everything that users experience directly: text colors and styles, images, graphs and tables, buttons, colors, and navigation menu. HTML, CSS, and Javascript are the languages used for Front End development. The structure, design, behavior, and content of everything seen on browser screen when websites, web applications, or mobile apps are opened up, is implemented by front End developers. Responsiveness and performance are two main objectives of the FrontEnd. The developer must ensure that the site is responsive i.e. it appears correctly on devices of all sizes no part of the website should behave abnormally irrespective of the size of the screen.
What shall you do
So you've learned to handle Fontend with react but you still need to handle backend but if you didn't know a language to handle it, don't worry.
You can use something like firebase and here is its link : Link
And also you can learn to integrate these 2 sides with this document: Link
Good luck
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
Both angular and laravel are great frameworks meant for slightly different purposes. Since they achieve to do similar things like -
They both focus on an MVC-inspired application structure, and each of them support a different directory structure by default
They both offer templating engines of their own, with conflicting syntax (which can be changed of course)
They both offer DOM iterators ( php foreach vs ng-repeat )
And many more similar conflicts
Since they are so similar in philosophy, isn't it redundant (and even conflicting sometimes) to develop a web app which uses both these frameworks?
Since each of them are so powerful in themselves, would it be a good idea to mix both? How common is the combined use of these in real world websites?
Am I better off using angular with basic PHP instead, if say, I was developing a medium scale web service (5000+ users)
What are some of the other backend+frontend framework combinations which are symbiotic and most frequently used?
Yes they can do similar things, but they don't have to.
Of course it doesn't make much sense to use the same feature of both of the frameworks. Meaning if you choose to use AngularJS for templating you don't need Laravel's views. But that's nothing you should worry about. If you don't use it, you don't use it. The fact that you don't use the entire functionality of a framework shouldn't have any bad impact on your application.
But note: Be consistent
Don't render one view with Laravel and use AngularJS for the other.
Recommendation
I personally have made good experiences with Laravel as a RESTful API and AngularJS taking care of the rest. So AngularJS is doing all the frontend stuff and communicates with Laravel only via JSON.
I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.
I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?
For example, we have the following departments in our app, they have distinct functionalities:
Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...
Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)
--- Pros:
Multiple programmers can work on different sub-projects in an agile
environment.
Each project is smaller and easier to be upgraded or replaced.
--- Cons:
We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.
Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.
--- Pros:
Now every component in the project can collaborate with each other.
A true Single-Page-App All-in-One app.html looks nice.
--- Cons:
Having hard time if multiple programmers are working on one Sencha Architect project.
It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.
Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.
Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?
First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.
Second for full disclosure I'm an engineer on the Sencha Architect team.
My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.
The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?
I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...
These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid
Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.
Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach
http://www.sencha.com/forum/showthread.php?243179
Asp.Net MVC is another good approach and might afford you some features like user auth etc...
Hopefully this helps!
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