As a newbie to Liferay I am investigating whether I used the right approach to populate data forms.
When populating a form with a number of text fields using an external REST service, I alraedy implemented the following approaches:
Creating a web content page and fill it with Ajax. Works, but using Jquery is not my preferred (modern) approach for accessing REST services.
Creating a web page using an Angular/React portlet, etc. Also worked for me. As I understand, per page I have to create a small Angular (module) project.
Creating a Form page that retrieves the fields by a data provider. Worked also for me, but this was presentation only.
"Service builders" are used in the examples for working with databases. I did not use this method yet.
Below are a few questions but there only 1 theme: when using Liferay, what are the beste techniques to populate data forms?
Is there a better/easier approach in Liferay to fill the form?
When using option 3, will it call the data provider multiple times for each field?
What if I would like to post the populated form data to the REST service?
Which approach is best to fill a table with rows of data?
Can/should "service builders" be used for interacting with REST services as well?
Is there a way to interact with basic components and Angular? I could not find anything on the internet yet.
I believe that your question is still out of focus for stackoverflow, as it's asking for "the best" way - to that, the answer is a firm "it depends".
You're listing a couple of options yourself. What you choose will in the end depend on
the technology you know
the technology you feel comfortable maintaining long term
the business requirements - e.g. how flexible to you need to be? can you go low-code, or do you need the full flexibility to develop an actual app
how frontend-heavy are your requirements
how independent of Liferay do you want them to be?
That being said: All of your options are good choices in various situations that you need to solve.
My general recommendation is to think maintenance, and optimize for the future maintenance of your solution, rather than the initial implementation time.
But, unfortunately, no firm single answer.
Related
This post is intended to start a deeper discussion on Single Page Applications for the web. There are questions that do not seem to have a clear answer in most resources on the subject.
They are in my mind
Authorization and authentication.
With entire web app being on the client, it may make calls to the server in any of its functions, even those that the user does not have rights to. The fact that the user cannot see a menu, does not preclude that person from invoking java script functions. This is easily handled in MVC app, for example, by using controllers that validate user rights to a specific function based on a cookie for example. However, some SPA apps just use single controller with Breeze or Web Api, which make authorization server side impossible.
Memory management on the client
For small sample apps this is not an issue, but imagine an app with 100's of screens or an app with a single screen that pulls thousands of records over the course of one day. With persistent caching one could imagine large memory issues, especially on under-powered devices with little RAM, like phones or tablets. How can a group of developers had SPA route without a clear vision of handling memory management?
Three Tier deployment
Some IT departments will never allow applications with a connection string to a database located on front end web servers. Every SPA demo I have seen is structured exactly like that, including Breeze or Web Api for that matter.
Unobtrusive validation.
It would require developers to use MVC partial views and controllers instead of just HTML files, which seems to fly in the face of SPA concepts, while it provides a very robust way to easily incorporate validation and UI to support it into web applications.
Exposing primary integer based keys in the url.
This is non-no in OWASP.
As a result, SPA applications "seem" to target areas with few security requirements and small feature sets. What do you think?
Thanks.
#Sergey - I think this is just too broad a question for StackOverflow. S.O. isn't a discussion forum; it's a place to go for specific answers. So while your questions are potentially valid, I don't think you should hold out much hope for deep substantive responses here.
May I add, in the friendliest possible way, that your sweeping, unsupported, and negative statements make you look like a troll. You're not a troll are you Sergey?
On the chance that you are in fact authentically concerned, I offer a few quick reactions, particularly as they pertain to Breeze.
Authorization. In Web API you can authorize at the method level. The ApiController base class has a User property that returns the IPrincipal. So whether you have one controller or many (and you can have many in Breeze if you want), the granularity is method level, not just class level.
Memory management. Desktop developers have coped with this concern for years. It may cause you some astonishment if you've always developed traditional web apps where process lifetimes are brief. But long-running processes are not news to those of us who built large apps in desktop technologies such as WinForms, WPF, and Silverlight. The issues and solutions are much the same in the land of HTML and JavaScript.
Layers on the backend. You've been looking at demos too long. Yes most demos dump everything into one project running on one server. We assume you know how to refactor the server to meet scaling, performance and security requirements for your environment. Our demos are concerned mostly with front-end SPA development. We do dabble at the service boundary to show how data flow through a service API, through an ORM, through to the database. We thought it sufficient to identify these distinct layers and leave as an exercise for the reader the comparatively trivial matter of moving these layers to different tiers. We may have to re-visit that assumption someday. But does anyone seriously believe that there are significant obstacles to distributing layers/responsibilities across server-side tiers? Really? Like what?
Unobtrusive validation. When most people start using the word "unobtrusive" in connection with HTML, they are usually making a point about keeping JavaScript out the HTML. Perhaps that's what you mean too, in which case SPA developers everywhere agree ... and that's why there are numerous "unobtrusive validation" libraries available. HTML 5 validation, jQuery validation and Knockout validation come to mind. All of them are in the SPA developer's toolkit and none of them "require developers to use MVC partial views and controllers". What gives you the impression that a SPA would need any server-side resources of any kind to implement validation with JavaScript-free HTML markup?
Ids as security risk. Really? This is bogus. The key value is no more a security risk than any other data value. Millions of applications - not just SPAs - communicate key values to the client, both in the URL and in the body. It's standard in REST APIs. It's standard in ODATA. And you want to dismiss them all by saying that they "target areas with few security requirements and small feature sets"? Good luck with that. I think you'll have to do better than rest your case on a link to a relatively obscure organization's entire web site.
I have built some SPA applications, ranging from small to large (over 100 scripts and views). Only a handful of them had every view accessible to the public. The rest went through a strict access structure. It was so simple to return a 401 unauthorized from the server and the client just handling the 401 to redirect it to the login screen. Mr. Ward and Mr. Papa put it right. Get out of the Demo mode and try to find solutions to the issues you come across. I have watched John Papa's SPA on pluralsight, gone through numerous articles and applications on Breeze and I have to tell you, none of my applications use Breeze to do queries from the client side, because YOU DON'T NEED TO!!
Moreover, I have only extended what I have learnt and come up with my own way of solving problems. This is not an answer to your queries, but I only can provide a short comment. No technique is perfect and there is no ONE way to do everything. My server side is locked down where it needs to be locked down, my routes on the client side are locked down (if using durandal take a look at guardRoute), my scripts are minified and my images are sprited (if there is a word like that). All in all, SPA is a great technique, you got to find solutions to the quirks!
I am a student developer with Oregon State University's Business Solutions Group and I am currently working on a Salesforce integration project for one of the University's colleges. As you can imagine, the data we are working with is coming from several different places and in a variety of different formats. I was wondering if anyone with more experience in setting up Salesforce object schemas could talk about the pros and cons of relational database style normalization in Salesforce. What do we gain by not normalizing and using Record Types to categorize data? (For example: a Person-Account that encompasses Students and Faculty and uses Salesforce Record Types to differentiate between the two) What do we lose?
This message was inspired by this webpage:
Salesforce Guru: Record Types
Notice that the first thing it advises is to not normalize (overmuch) because it prevents us from taking advantage of some built-in Salesforce functionality. Overall, the page seemed helpful, albeit incomplete.
The answer to this question seems critical to the success of our project and will help us to decide how to reorganize the data we are initially migrating to Salesforce and ultimately build our Salesforce object schema, so any thoughts, additional resources or advice are very much appreciated. Thanks!
The inspirational web page is correct. With the "standard objects" like Account, Contact, Case, Lead, etc. and even with custom objects the system works best to use fewer tables (objects) and segregate the data based on some value (such as record type).
By using record types you leverage the point-and-click UI. For example, for the Account object you have a default page layout. But for each record type you can have a unique page layout. Furthermore the security model uses record types to limit or grant access as appropriate to different user profiles.
As the author says SOQL is NOT SQL.
How can I communicate in a very simple and effective way the path the user takes through my application?
I'm currently working in a Ruby and Rails environment, so I tend to visualize my application in terms of RESTful URIs. So for example, if I want my users to sign up, I could match a new route called /users/new. The thing is, I would like to see beyond that specific action, and visualize how many pages or forms does it take to create an account and some business logic associated with the process in general. In other words, I'd like to see a mix of a workflow diagram and some implementation details (at an interface level).
I was thinking in showing mockup pictures wrapped in boxes, and relate them through arrows with their corresponding GET, POST, PUT, DELETE methods and URIs attached to them. I think it is a good idea, but I haven't seen examples yet that inspire me.
In your experience, what helps you see the big picture? Balsamiq mockups allow to define links and navigate through the app, but it doesn't help to conceptualize.
Have you thought of using a mind-map? You could try the free FreeMind
If you stick with UML, you could consider an Activity diagram.
I think you're on the right path. Showing different screens with possible combinations of users' transactions between them is a good technique. Basically you would be able to show user's flow through your application and stress out decisions a user will make on the way.
The good example for it was presented here http://vimeo.com/43869717
This technique called Storyboarding. You should be able to find some examples. But the one I mentioned above is one of the best Storyboarding techniques. I use it all the time to show the big picture and present application workflow from user perspective to my team.
I have a web application with a user base. I want to add a forum, but I don't want users to register there again.
I'm using Rails/Postgresql.
Is it possible to integrate the forum so that after registering in my site, a user will also be registered in a forum?
Thanks
Yes, it's possible. The simpler way is to centralize registering and authentication through the forum.
Implementation depend of what kind of forum you use and the structure of your site.
The packaged forum should have some kind of API that you can use to programmatically add a user when they register with your main site. If not, you can just write to the tables yourself (which is considerably riskier, but certainly doable if the forum software isn't ridiculously complex and over-engineered).
You may need to add some fields to your site's registration if the forum software requires some that you don't already have. If that's the case, the bigger challenge will be integrating existing users. You might have to use dummy values for them, or prompt them at their next login to supply the necessary values in order to complete their forum registration.
When using some existing forum software in a larger web-site, how easy is it to:
1)Make your site's login functionality log the user into the forum
2)Make your site's registration functionality create forum login data
I suppose in a way it might be easier to ONLY use the forum's database for maintaining users, but that means trusting it with sensitive data.
I'm planning an integration between an existing bespoke desktop app and a new bespoke web-site which should include forums. I don't know which forums will be used but I know the new web functionality won't be PHP-based. I figure that's not a big deal but I'm wondering if forums typically allow configuration of where they look for login data, to avoid duplicating this data into my DB and the forum DB.
It's usually pretty easy, but it completely depends on the Forum software that you choose.
I've written systems in both PHP and ASP.Net (C#) that integrate with phpBB or vBulletin databases.
The login functionality is the easiest part to implement because the hash is stored in the DB (usually a salt will be too), and you just need to check one field to another and voila you can authenticate!
The registration of users is a little more difficult.
The way I did it was browsing through their source code to find out what SQL commands were necessary during the registration step.
So, depending on the forum software you choose, the difficulty will change, but overall it's not to difficult to make happen.
I would offer you snippets on how to integrate with PHPBB and VB, but since those are both PHP based, you said you weren't going to use them.
You are actually looking for a Single Sign On feature, that is integrated in several forum softwares, like Simple Machines and JForum for example.