I am intending to build a fairly comprehensive (read: complex) search form using razor pages in a dotnet core webapp. One of the features of this page will (I intend) be live/dynamic updates (search results refresh as search parameters are typed/chosen) and that the displayed browser URL is updated to reflect the search parameters as they are changed.
In order to prepare for this I've been looking for documentation on how to build this page and it seems to me that while Razor pages are easy (fun?) to build for basic page designs, having dynamic (read: partially refreshed) components requires the use of more basic (read: not framework supported) JavaScript.
While I have found articles like this which document how to do the 'live update' I'm not sure if this is really the best approach.
I don't know if frameworks like VueJS (which would be the alternative option, due to in-house skill set) make dynamic/live updating of the browser URL any easier (by virtue of their framework features).
Does VueJS, though it is more front-end heavy, provide a stronger platform for developing a live/dynamic refreshed page than Razor pages or am I simply missing some fundamental (perhaps too easy?) feature of Razor pages which provides for quick/easy development of dynamic, partial page updates?
Related
I've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!
I'm already familiar with Knockout, Angular, Sammy, jQuery, a little breeze, and a little ember. The tutorials and getting started for Durandal all seem to be saying... well first add jQuery and maybe knockout.
Does it handle something entirely different than all of these?
What need does it address such that it is likely to be used with knockout?
Is it just a hodgepodge of client side routing and ui components?
What does it do on its own conceptually?
Durandal is similar to Angular in that it provides a MV* framework for client-side SPA web applications.
Angular is mostly, if not all, custom code, whereas Durandal takes existing libraries, mainly Knockout and RequireJS (Sammy dependency has been obviated with the 2.0 release), and provides the plumbing to provide full SPA functionality, including view/view model composition and hash-tag (spa) navigation.
As for Knockout, Durandal relies heavily on Knockout to compose the views and view models. Your view and view model are automatically data-bound when the view is injected into the DOM. The advantage to this is that I can use Knockout to provide the V/VM data-binding, and let Durandal do the work of figuring out which v/vm to use, retrieving it from the server, and composing it into the current screen.
Restated, Durandal provides a way to map views/view models to hash-tag based routes, which give you the SPA navigation. By specifying a shell, or layout, view as the main view, a placeholder can be added which Durandal uses to implement what is basically a "screen presenter" pattern. Durandal listens to the URL changes, and can automatically activate, data-bind (using Knockout), and display the view that matches the current URL route.
If you're familiar with WPF, you may think of Durandal as providing Prism-like functionality as its main offering, along with other goodies designed to support building single-page-applications for the web.
Durandal has several benefits, but also builds on existing libraries. It has a dependency on
RequireJS
Knockout
jQuery
These are not "maybes." They are hard dependencies. Durandal cannot work without them.
At it's core, Durandal add's the very powerful compose binding to knockout. This binding will automatically locate the view (an HTML file) when passed a viewmodel, retrieve it from the server, bind it to the viewmodel, and insert them into the DOM. Similar behavior can be achieved using the knockout template binding, but managing the templates can become cumbersome. Composition also adds lifecycle events to the process, which can help ensure that viewmodels are setup and torn-down correctly. It also provides optional DOM caching.
Durandal also provides some framework structure. It provides a simple plugin API, which is used by its router to give SPA navigation via hash or push-state. It encourages the organization of viewmodels and views by overridable convention, as well as the use of Require AMD modules. It also provides a simple event module to allow application wide events to be created and consumed.
Durandal is a "full featured" SPA framework, whereas Knockout is just data-binding. It is similar in scope to Angular.
Magento 2 stand on Knockout and RequireJS.
Durandal can be added on top of it so more possibility come with use latest features (components, templates etc).
It is better because:
it is more stable and major than other framework, less errors occur
great documentation
simple api
more SEO friendly! (you can have all html seved and use it like component, mixed situation). Angular 2 stand on mixing logic with presentation.
html5 standard data and binding with better code redability (just try read html in react)
still maintained
creator of Durandal was for some time Angular Developer (3 month) so there is some similarity going on there in thinking.
Work in old browser ! (IE6 >)
There also cons but mainly because it don't give so much function in one pack and not newly, cutting edge technology, was adopted.
Pleas share more point about Durandal :)
More there: https://johnpapa.net/compare-durandal-to-angular-not-knockout-to-angular/
We write a lot of intrasite modules and are noticing that they really deviate now in SF 4+ from the content-based ones. So, on that note, I have some questions:
How do you get the EXACT look and feel of the standard modules for the edit/create form? For example, how do you eliminate the menu above, center the form, etc, as in, say, the Events module?
How do you add an actions menu dropdown to a radgrid, same as you'd see in the grids for standard modules?
How do you incorporate Sitefinity fields into the usercontrols? For example sf:ImageField throws script errors when added to a control? Also, is there documentation on each of these fields and how to configure?
---finally---
If we really want that standardization, do we have to go with another module type?
4.Is there a module type that will allow us to access non-sitefinity data (ie separaate db
but also provide us with exactly the same functionality and UI experience as the content-
based modules?
intra site modules are simply custom user controls (ascx) placed into backend pages to add your custom functionality to the backend. To copy the look and feel of the rest of the site, I literally copy and paste the HTML into the control.
I did a webinar on this a while back, including code to recreate the backend editor. It appears to still be valid, and is available here: http://www.sitefinity.com/blogs/joshmorales/posts/josh-morales-blog/2011/06/30/sitefinity_intra-site_module_webinar_notes
the centered view is a bit different, and I don't have that html, but you could potentially do the same (copy it from another native page). I don't always get it 100% accurate (my controls are usually laid out different from what Sitefinity does) but I get close enough so that it doesn't break the user experience.
The actions menu could be recreated with javascript, but if you are looking for NATIVE integration that does all this for you, indeed you would be looking at inheriting or much better yet: simply using the module builder, which lets you build custom types that automatically install themselves into Sitefinity as if they were regular modules.
Fields are definitely designed to run inside the context of native sitefinity module definitions (the classes that make up the UI using the Sitefinity context). This doesn't mean you can't include Sitefinity content in your modules; it simply means if you do you'll have to implement the integration yourself using the API.
On your last question, the only way to use external data but still keep the "Sitefinity Content" UI is to inherit from Content, then create a custom provider that reads from your database and translates it into the Sitefinity content type. It is certainly possible, but is quite a big project.
Unless you are in full need of this tight integration, I recommend simply going intra-site, linking to Sitefinity content types,taxonomy, etc through the API and manage it separately.
I hope this was helpful!
I've been recently experimenting with one of the widely recommended MVC client-side frameworks (Backbone, in this case). I find it quite nice, but I have an issue with it: suppose I'm building a list of contents, which I want to present on browsers using client-side rendering, but also want to make available for search engines, which do not run javascript. That means, I'll also have to render stuff on the server-side. Now, let's say I'm using Handlebars.js, whose template language is inherited from mustache. All is well. But on the server, I'm using ERB (or HAML, whatever). That means, I'll have to support more than one version of the same template. Which is just unmaintainable, for cases where your templates going beyond the list-element 4 lines of code. How are the big platforms working around this issue?
I've been recommended the Click framework from Apache. But I can't find any forums talking about benchmark, reviews, advantages, disavantages, usefulness, ease of implementation, etc.
I've been asked to use it to develop a web site, but I'm completly in the dark about its strengths and weaknesses.
And its damn name isn't helping !! Click ? Hey Apache ! Call your next framework "the" just for fun. I dare you.
So can anyone comment on his experience with Click ?
What I personally like about the Click framework is that it is fairly close to HTML/HTTP and the Servlet API. There is no huge abstraction to get familiar with. You have a Page class, a Form class, ... If you need to preserve state across invocations you put it in the session or you pass it through the URL... This makes it easy to start using it. It is also straightforward to control the HTML pages being generated. It may sound like it is a very basic framework but the simplicity is actually one of it greatest strengths.
Other frameworks (e.g. Seam) are more suitedr to create a very large web application with lots of reusable components and complicated pageflows but the learning curve is much steeper. So for me Click works well for small to medium sized websites.
It's an apache incubator project but that does not mean the project is not stable, rather it reflects that it is in transition to the Apache project model.
Click is Apache's version of a component based web framework equivalent to JSF (other component base Java Frameworks are Tapestry and Wicket)
Click is rated at Ohloh
There is an official blog and some Wikipedia references: Framework Comparision and info page