I'm looking for suggestions on how to "separate" a front-end and back-end without too much added complexity. The purpose is for a blog application (I know others exist, I just want to roll my own). A couple simple index/view views for a front-end with more complex (index, create, update) views on the back-end.
For example, I'm am currently building a website using the advanced template and it's working as desired: different layouts for the front-end and back-end admin area, navigating to "/admin" takes you to the admin area, etc.
However, I don't need separate authentication, don't really care about separate controller logic, don't need a "view" action on the back-end or a "create" on the front-end. Though, it would be nice to have the URL include the "/admin" prefix for those administrative functions
Is there some easier way to give myself the experience of a separate admin area without going through the added complexity of separating backend/frontend/common apps/configs?
The simplest way of doing that is to create a module entitled admin and set up some access rules on it.
Even simpler is to create a controller called admin..
What you choose, depends on how many admin actions you need.
The advanced application template is indeed going to be overkill for the majority of Yii applications.
A careful mix of RBAC and module/controller magic will get you where you want to go, I hope. ;)
Edit:
I recommend integrating as much admin functionality into your application (views) as possible.
if (\Yii::$app->user->can('whatever')) {
// do whatever
}
That way, the amount of stuff that the admin has to manage in the pseudo-backend can be shaved down considerably. :)
See: Yii Guide - Role Based Access Control (RBAC)
Related
I'm using Wix as an e-commerce solution and the way I understand it, I can only add code (not edit current code) to make specific changes to the site. The one change I want to make is to have the ability to authorize/capture PayPal payments at a later date for all the products I am selling.
I've read through the PayPal authorization/capture documentation here but am still confused for my specific use case considering the only button I have is a "Check Out with Paypal" once customers have added products to their cart as opposed to "Buy Now" or some of the other button options available.
Is there a way to easily integrate authorize/capture in this case and if so, can someone help me out with how? Hoping I can make one change no matter how many different products a customer is purchasing that allows me to either capture all or part of the entire purchase amount and void the rest.
I've scoured the internet, but don't feel like anything I've come across is directly applicable. See here and here. The latter link makes it look insanely easy, but again I think the problem lies in the fact that I'm using Wix and can't directly edit existing code.
If anyone can provide directions/code necessary to implement this I'd be extremely grateful. Thanks so much in advance!
Note: It appears Wix integrates with PayPal Standard and all I need is the "Basic Authorization" capability, NOT "Order Authorizations."
The latter link makes it look insanely easy, but again I think the problem lies in the fact that I'm using Wix and can't directly edit existing code.
You've nailed it. It would be that easy, just add the parameter paymentaction=authorization when redirecting to PayPal, but Wix needs to provide a way for this to happen.
Many shopping carts -- especially those that integrate via an API rather than Payments Standard -- have a checkbox in their settings to toggle on authorization mode vs. immediate capture (sale) mode. The reason API-based integrations are much more likely to implement such a setting, is that an API is needed for the shopping cart to be able to capture the authorization at a later point in time. API-less integrations (like payments standard) cannot do the capture themselves (because this requires an API call), and so with standard you'll always need to log into www.paypal.com for the capture later on.
Anyway, there's probably no way forward unless Wix provides you with one.
Wix could well be using an API integration rather than the HTML-only Payments Standard, but the problem is the same: the API needs to specify 'authorization' (instead of 'sale'/'capture'), and from their lack of documenting the feature it does not appear Wix has implemented this.
Most shopping cart/platform providers do support authorization and capture, so you could make the feature request to Wix, and/or consider switching providers if it's a must-have.
On a general note, using authorization and capture adds complexity to payment processing, and the capture is not guaranteed to be successful. You can get a successful authorization and then have the payment fail when you try to capture it (happens in a certain % of cases, when funds are no longer available or the card decides to decline). So in general, you use immediate sale/capture at checkout time (not authorization) unless you have very specific and well-defined business needs to not be capturing up front (and refunding in the case of exceptions).
We are developing a SaaS-application and currently facing the situation that different customers ask for different customizations. I have already googled and read a lot specifically about Multitenancy. I am also familiar with the Strategy Pattern.
But this still leaves me a bit confused about a good concept for an Angular 2+ application. Business logic is not gonna be the problem, as I can use Angular's dependency injection to load and use customized services for different customers. Also theming itself is not a problem, as we use Angular Material which has a nice theming engine build in. What does give me a headache are the templates itself. Of course I can use *ngIf and *ngSwitch within the HTML templates, but this is exactly the kind of code I want to avoid, because it will become horrifying once reaching 50+ customer versions.
Let's have a real life example. On a search-page all customers can search for objects and export single objects as a file download. One specific customer asks as to implement a mass export in a proprietary file format which needs a new button in the page, which obviously all the other customer should not see.
The three options I can think of for this scenario (and none of which I really like) are the following:
as mentioned before working in the template itself with *ngIf and/or *ngSwitch*
using the theming capabilities of Angular Material and working with css-only (display: none;)
maintaining multiple versions of the component (depending on the needs using component inheritance) and loading the correct version of the component depending on the user
All of them have obvious con's, just to name a few:
Nightmare to maintain once customer numbers grow and customizations become more frequent (think of a bigger component with 6 differentiations and 50 customers ...)
for now actually my favorite, but functionality not really disabled, just hidden (of course the back-end checks for permissions, but still more information is transferred to the users then necessary)
works well for the code-part of the components, but would mean to maintain massive amounts of duplicate template-code
I am sure we are not the first to tackle this issue. Am I overseeing any solution with less disadvantages? Are there any code patterns that I could apply here?
edit: after more discussion in our company we realized that there is another important point to this: some customers are hosted on their own servers, but most of them are being served from one central server. This means that the optional features have to detected and added at run-time, which implies some kind of awkwardness.
So our approach is to extend our existing licensing database to also contain the customer specific functionalities, which then obviously only that customer has a license for. Now the easy solution is to have a license endpoint and get all the licenses the customers has acquired, then every optional function can just sit in a simple single *ngIf. I appreciate that this is a simple and clean solution, but it offers the potential to find out some business facts about other customers of our company (by unobfuscating the code and finding additional endpoints etc.pp.). So probably combining this with server-side rendering would be the best solution I can think of right now.
Of course I don't have a clear cut solution that would totally fit your scenario, but here is an idea.
Divide your page into components that act as container regions.
For each customer create a customer configuration that would say
which atomic components goes in each region.
Create atomic components in which each component can be a single function isolated from the rest of the other components. Rely more on services to communicate between them. As an example for this atomic component is the button that create the new export in your example.
Create your page dynamically using ComponentFactory.
I have used the same approach before to customize a design toolbox based on a slide template (like powerpoint slides templates).
As for the options you mentioned, here are my 2 cents:
*ngIf and *ngSwitch, you can eliminate these if u create ur components dynamically and use granular or atomic components.
I don't think this would be a good approach in terms of architecture
and design. You are just manipulating the view css
If you use transclustion, this can minimize your code base if you
can group the components efficiently.
I hope this helps.
I am a beginner web developer and working on a school project. My apologies for asking this basic question.
I am trying to create an online shopping store. What I am trying to do is when the user clicks on the checkout button, the shopping cart page gets updated with that element.
I don't know how to accomplish that. I really appreciate if someone can point me to a tutorial or provides some tips.
Your question is really abstract, however you will have to find the right way to communicate with a database...it might be php/MySQL with laravel or some other framework or preferably C# asp.net with entity framework(that's what I will go with its not mandatory some people like php) Then you need to learn some lambda or sql depending on which approach you would like to take (php/C#). You will probably need to get some kind of grid control for the cart asp.net has default one personally I find it confusing and hard to work with( there are many controls that can be downloaded freely without charge for non commercial products search google) then you would need to fill that grid with the List of objects that you will get from your database. If you get that far alone the next steps would be easy you will probably need some javascript for ajax calls to a webservice or either your backend so you can submit the orders. For the right tutorial there is none actually since your question covers several topics regarding database modeling, data fetching, backend development and front end development. You can start by getting yourself some kind of server (look for mssql for asp.net) and MySQL for php, then you should look for some kind of database modeling tutorial basic tables relationships 1-1 1-* *-1, after that you would need to do your design (from the question I assume that you already have one downloaded). Then if you got down to this step you should google the way for the right way of communicating with your database from the backend of your website (I advise entity framework its clean and easy) you can generally bind the list of objects directly do the grid that would represent your cart (I say grid but you can give it data template to look like html, not to be confused with regular tables). If you really get here I see no reason to keep coding for a school project in most places you can use all this to bachelor degree exam and pass with straight A. But if you want more details look into these videos they explain quite well what you want to do.
https://www.youtube.com/watch?v=s91pPLx_T3Q
https://www.youtube.com/watch?v=yYr0seXj7qA
https://www.youtube.com/watch?v=lFkXk5gHjSs
I am not great at JavaScript but I think your page would need to update a cookie then read that value from said cookie. I hope that's a good place to start!
You might also find "Creating a Shopping Cart using only HTML/JavaScript" helpful.
I'm developing a website and need to create an ERD for the website. I've never created one before but will be using MySQL to design it once I figure out the tables necessary. All I am asking for is for ideas on what tables might be necessary for this website. Here is a link to an image of the website:
!
Obviously there needs to be a user table. I have that created already with all pertinent info. Do I need to create a login, register, home, elite login, photos, events, newsletter, and contact us tables? The photo link will bring the user to a page where there are folders for each event, if you click on the folder it then opens up another page with the actual photos, but you need to be a registered user to view these. Is the login hyperlink going to be the user table? Would the register link be to another table or would that add to the user table? The events page is only going to be a list of hyperlinks that take you to a new page with dates and descriptions of the events, does this need it's own table? And lastly does the newsletter and contact us pages need separate tables as well?
Like I stated, I am not looking for anyone to help create the dERD but only to let me know if all these tables would be necessary. From there I can build the ERD and create the appropriate relationships and so forth.
You would probably benefit from learning about MVC- Model, View, Controller systems.
Views (in a webapp) map pretty well to the HTML pages you display.
Models map pretty well to the "Nouns" in your system- these are the things in your database; Users, Photos, Newsletters are examples of things that go here.
Controllers map to the "Verbs" in your system- Register, Subscribe, Upload, Save, Login are all actions that a controller might provide.
Only the Model layer lives in the database in most frameworks.
I'd suggest that you think about your problem in a more holistic fashion, rather than diving into diagramming a bunch of unrelated ideas. ERD's really only map to the stuff you need to be persistent.
I would recommend that you first draw paper prototypes of most of the user interfaces, at least at a high level. Then do usability tests on those prototypes to make sure your interface designs make sense to someone other than you. (User Interface Design by Soren Lausen is a good book for that.)
Then, once you have a decent idea of how your interfaces are going to work, think of the models necessary to make those interfaces work. Obviously, a login form with a username and password will require a User entity with username and password (or, actually, encrypted_password) attributes. Getting all these models nailed down may take some skill that I sense you may not have yet, but this task will be much easier and clearer to you if you have your interfaces drawn out than if you're just trying to sit there and think about it. Your first pass will probably be wrong, but that's okay. Start with the smallest subset of the program that could be useful on its own, build that to the point where it's completely working, and then expand from there.
Good luck!
After looking this over I have come to realize that I have jumped the gun quite a bit and need to do a lot more work on the design of the site before even thinking about the ERD. The client has only approved the mock up of the "home" page and the other pages have yet to be discussed at any length. Nothing is set in stone as it were. Therefor, creating an ERD is very premature. Many thing, from now until the database needs to be looked at, can change.
Please excuse this topic as I was overly excited about my first project. I need to focus on the agile development process and slow down. Focus on the individual steps and let things develop from that.
I'm working on a web application (Java EE backend) which contains a fairly complex input modal. This input modal allows the user to capture data, but it has a bunch of (JavaScript) restrictions, such as mandatory fields, fields only being available if a specific value is entered, etc.
I have to expose this functionality to external systems and allow them to submit this data to my server. These external systems can be both web or client based (but I can assume that the clients will have internet access). My first thought is to provide some kind of definition of the fields and stuff like mandatory to these systems through services, and have them render the input modal however they want. This has been met with resistance though, because the types of fields and restrictions will likely change quite a bit during the next few months of development. These external systems have different deployment timelines, and for this to work we'll have to firstly duplicate all the logic handling these restrictions across all systems, and secondly synchronize our deployments.
An alternative which has been proposed is to have the external systems call my modal through standard HTTP and render it either in an iframe or in an embedded rendered. This solves all of the previous complaints, but it leaves me feeling a little uneasy.
Are there any alternatives we are not thinking of? Maybe some kind of UI schema with existing render libraries for the different platforms? What are your thoughts on the second proposal, any major concerns or is this the "best" solution?
Edit: To clarify, I'll of course still perform backend validation regardless of the frontend decision, as I can't just trust the incoming data.
The constraints that you mention (mandatory fields etc.) really have nothing to do with the user interface. You are also right that it is not a good idea to have your backend render web content.
Your first proposal sounds like a good idea, here's how I would solve the issues you mentioned:
Do all the validation on the backend and send a model object to the client, representing the current state of the UI (field name, type, enabled/disabled, error message etc.).
Keep the client as dumb as possible. It should only be responsible for rendering the model on a window / webpage. Whenever a field is changed and it requires validation, submit the model to the backend for validation and get back a new model to be displayed. (You could optimize this by only returning the fields that changed.)
Doing it this way will keep your validation logic in one place (the backend) and the clients rarely need to be modified.
I have been faced with same issues in several previous projects. Based on this experience I can honestly say that server-side validation is the thing you will likely have to implement to avoid rubbish being committed from client side regardless if it comes from GUI or other third party system via API. You can choose one of available validation frameworks, I used Apache Commons Validator and think it is well, or you can implement your own one. On the other hand client side pre-validation, auto-completion and data look up are the solutions you should have to make human users happy. Do not consider about code duplication, just make your system right way from the business point of view.