I have just picked up Vue and am trying to figure out the best way to structure this project.
Requirements:
A basic MPA (traditional site) with about 6 pages. This will be static info.
There will need to be a login section where customer will transmit data via form. Payment will happen here as well so will need to be secure.
My question is how should I be using Vue here? (I've already used VueCLI to scaffold out the project)
Should I:
A) use it for some components (Navbar, buttons, forms, etc) and keep structure traditional? How would i build out the User Dashboard to submit form info in this case - just as a new page?
B) or should I build this whole site as a SPA and have the new 'page' info loaded in on click? This would be easier for the login section?
One thing that may be clear on reading this is I don't understand well how the site will recognize users and deal with logins. Would this be easier if it were structured as a SPA? (more secure?)
(Also, I'm using this site to teach myself front-end development, specifically would like to learn more about building SPAs - so I realize I could use a web editor or easier solutions, but want to learn how to do a lot of this from 'scratch')
From what you've described it is entirely up to you. Both SPA or MPA would work fine and either would be totally reasonable given the requirements.
Have you worked with Vue-router before? SPAs don't need to appear as a single page to the user. They can still function as an MPA with different routes, page files, permissions, etc.
If you are hoping to use this project to teach yourself front-end web dev and know you have a particular interest in learning about SPAs, I think that is your answer.
I would go with an SPA and set up vue-router to manage your routes, and pages.
Related
I have webiste which is available in the internet. Front is written in Vue.js and CMS is created using Laravel (PHP). These are separate applications.
Unfortunatelly Google dosen't see the page because of lack of SEO (yeah! Vue). The website is big, has a lot of routes, fetches data from API ex. for a blog.
Here is my question. What is a better solution? Move website to Nuxt.js or use some fancy plugin like https://github.com/chrisvfritz/prerender-spa-plugin and fetch data from API.
I'll be gratefull for any tips!
Use #prerenderer/renderer-puppeteer if: You're prerendering up to a couple hundred pages and want accurate results.
Use #prerenderer/renderer-jsdom if: You need to prerender thousands upon thousands of pages, but quality isn't all that important, and you're willing to work around issues for more advanced cases. (Programmatic SVG support, etc.)
I have started to work on a greenfield web project which will use ASPNET Core and Aurelia. I cannot find a definitive best-practice approach to structuring this on the client. My current thinking is that each app feature will be be a separate Aurelia application, i.e. when a visitor clicks on the link "Accounts" the browser will make a server request to https://example.com/accounts. This will return a single HTML page which bootstraps an Aurelia app just for accounts. All the accounts interaction will be delivered using Aurelia. Similarly, if the visitor then clicks on "Dashboard", another server roundtrip will bootstrap the "Dashboard" Aurelia app.
Is this a good way of approaching the problem? I have some concerns around application state - in that there will be cross-cutting concerns and data which I don't want to keep round-tripping to the server every time I need it, e.g. audit logs, user information.
I see that Aurelia has the concept of Features - semantically this is exactly what I want as each of these areas of the app will be delivered as a feature. However, I cannot find any good examples of the use of Aurelia features.
Any comments or experiences in similar projects most welcome.
I don't know if it's the 'best' way of doing it but a lot of the applications I build are user / admin type products.
Rather than building an application for each side I take advantage of child routers and structure my application with a page based convention as described here:
https://ilikekillnerds.com/2015/10/how-to-structure-an-aurelia-application/
I'm new to Bigcommerce but experienced with web app development. I have a need to make customizations to a Bigcommerce store where I need to implement custom logic that runs on the server-side which affects the output in the UI by deciding which page to serve. For example, I want to have different versions of a product page for different locations. I want each version to have a static URL, however, for SEO purposes. I need to implement logic in the server-side to do something like detect user location based on IP and then determine which of the product version pages to serve. I realize I can do this with JavaScript but I don't want to as I don't think that would work as well for SEO.
I have looked over their API and templating briefly but am not seeing a real way that this is possible. Wondering if anyone can guide me in the right direction or is Bigcommerce too simplified to allow this sort of customization?
You do not have server side access on Bigcommerce. The only would to do this would be client side with javascript.
I'm embarking in my first spa mvc 4 app and I've watched the Steve Sanderson talk which was great but his final delivery tracker app ends up with 3 views that are all declared in the same view page. This is fine for a small app but how do you manage this on a larger scale when you have different sections of the site that have different data. The site I want to build needs to remain on a single page because I want to keep a chat window open similar to the Facebook style chat and i am going to be using SignalR to push data to the client in fixed sections within the app. Do I just use the #Ajax.actions to load up completely different sections of my site much as I would if I was just creating a non spa site? The plan is to keep the user in a specific section of the I site for a majority of the time, but I will want settings pages and user profile management pages that are defined in separate views.
Any good sample code would be greatly appreciated I'm planning to just use the bog standard spa with knockout and nav.js unless someone can suggest a more mature spa technology for mvc/entity framework that's got some good documentation and is popular.
What I do is poor mans SPA, which is basically make my site like a standard ASP.NET MVC app so I have multiple views, multiple controllers and actions and I have a shell page with a container div which I use as the container for the whole site to load my views into with Ajax calls, so I have lots and lots of jQuery ajax calls, I've somewhat tried to refactor my client side JS and make a generic navigate to Javascript method (among other things) in my shell page, which I then invoke from the child views, so a click on a certain ActionLink in a particular child view and I would call my generic JS page loader:
GoToPage(controller, action, query)
which will use jQuery Ajax to lad the destination controller/action/view into the container div in shell.cshtml. For navigation I use Ben Alman's hashchange plugin to detect hash change events and load the appropriate views into my container div. There are obvious downsides to this approach as you're rally not building a real SPA, you're making a server side app with a SPA facade, and actually the performance difference between this and a proper spa which only gets data from the server (not HTML) is slightly noticeable, however if you're a traditional ASP.NET MVC developer this saves you from having to take up new libraries like Sammy.js and knockout etc. The biggest downside of this is that you'll be writing a lot of repetitive wiring javascript which can quickly become a tangled mess, especially if you have a lot of forms. Though you can take certain steps to re-factor and reuse common code. So in summary generating views server side and retrieving them with Ajax probably isn't the most optimal SPA solution, but for me it had the least learning curve (none actually lol). I've recently been looking at Durandal and I think it finally provides a very viable solution to creating SPAs, I specially like how unlike Sammy.js you don't have to load all views on the initial page load, even if the user isn't going to visit those pages. A nice getting started tutorial is provided here.
I am in the process of converting a web application that has been in play for some time into a Sitefinity 4 managed site. There is plenty of documentation on how to use the software to CREATE a new site, but I've found precious little that describes the process of how to migrate from non-cms to Sitefinity.
So - specifically, I would like some guidance on the process of conversion from non-managed to managed. I've been searching google and the Sitefinity forums, etc. but finding nothing except how to migrate from one version of Sitefinity to another - not what I'm trying to do.
Any leads for web sites to visit or documentation pages to read would be very helpful.
You'll have to bite the bullet and invest more resources at the beginning of your project and not release anything for some period of time. You won't be able to drive your car without fundamental components. The same principle applies here.
Whatever your requirements are, you will either have to hack around the CMS and then fix the hacks later, or do it properly from the very start.
Look at your existing site and break it down into smaller chunks
Consult Sitefinity documentation/partners/freelancers on how your existing content can be migrated onto Sitefinity platform
Task up the migration and start implementing
This is very rough guideline, but so are your requirements.
To summarise, there is no quick way. You'll have to do it properly form the start, or invest more resources later on bug/hack fixing.
If we have Sitefinity at the root of the application, we cannot,
according to Sitefinity, have any pages not managed by SF
That's not entirely correct. Sitefinity allows you to add "external pages", meaning that you can create odes in your sitemap which would like to external pages. Thus, your navigation in Sitefinity would show a complete website page structure, while some of the pages in that structure would actually be linking to external ones.
It would be absolutely easy and quick task to create your page structure programatically.
actually this is quite simple to achieve. Sitefinity is completely dynamic CMS (meaning, no real files). The implementation uses RoutingEngine and VirtualPathProvider to achieve this. What this in reality means is that you have two solid and standard extension points to split the site in "sitefinity managed part" and "custom managed part".
So, a very simple way to do this is to simply register a route (more info here: ASP.NET routing) before the SitefinityPageRoute, as SitefinityPageRoute will throw 404 if it cannot find a page.
So, let's say you register a route "~/mystuff" before SitefinityPageRoute, all the requests that start with "~/mystuff" will first go to your RouteHandler where you can decide to handle them (write to http response) or do nothing and let it fell down to Sitefinity routes.
Another way is of course to implement a custom VirtualPathProvider, however, this may be an overkill if you simply want some pages to be handled differently.
All this being said, it's obvious that pages not handled by Sitefinity will not be handled by Sitefinity :) (so, no page editor, no workflows, no translations, no widgets, no templates, no themes).