So this question came up today and I didn't have a specific or scientific answer.
What are the costs associated with using jsf (or tomahawk, faclets, etc., etc.) tags in place of traditional html tags. My gut reaction is that you should use jsf tags in situations where you need the additional functionality they provide, and use traditional tags when you don't. Also I feel like jsf tags would require more resources (since the server has to take them and rerender them as html anyways) than html. Does anybody know what the cost actually is (as far as time and memory)? Also useful information is what is the convention that is in use, pure jsf or a mixture of the two?
Sure there is a cost. Whether that is noticeable or negligible depends on the hardware and the load of the server in question. Profile it and upgrade the server if necessary.
You should however realize that on the other hand you save time and cost compared to implementing the same without help of a component based MVC framework. That's going to be a lot of boilerplate code gathering the paramters, doing validations, conversions, updating model values which is possibly not written efficient as compared to existing and widely used MVC frameworks.
The Sun JSF development team puts performance as high priority and Mojarra is already optimized as much as possible.
Our site http://www.skill-guru.com runs on JSF/ Tomahawk / Rich faces on a tomcat server. We do not see any speed issues here.
As Jeff pointed out , it all gets compiled so there is not much noticeable difference until and unless you really use too much rich faces or other fancy stuff.
JSF does help you make your life easy.
A JSF page gets compiled upon first request (or pre-compiled if you specify that in the config). Thus, it's not like the page needs to be parsed every time it's requested. I don't have any specific numbers relating to time/cpu/memory cost, but I'm sure it's negligible.
Related
A little background first, recently began coding and I decided to take the "learn as you go" approach as this is solely a project. I have a pretty good handle of HTML and CSS, I have an understanding of Jquery, and haven't even begun to look at other languages.
So basically I'm making a suedo-e-commerce site, and I'm trying to create a page layout comprising of several divs stacked together (think standard catalog page) Creating the modules and every static with HTML and CSS, but I want to add the content, comprising of a banner and some text blocks, dynamically from a database. Now, I'm pretty sure that I will have to use SQL and reference each entry with the HTML, but I have no idea how to do that or where to even start. So I'm asking if someone could point me in the right direction with some reading material, or some examples would be awesome.
You need to use one of databases (MySQL, MSSQL etc.) to save data. In order to show data from database you need to use one of background/server side programming languages. For start I would suggest that you try with php.
W3schools is good starting point for you.
This is very simplified and I hope not condescending. Consider separating how you collect your data and you present your data (the 'view layer'). SQL will help you pull / organize your data, and you could just string functions to add formatting (e.g. div's) to it, but you are better off investigating templating HTML. What happens when you want to put this data into a ul list or something? You have to re-write your perfectly good SQL. Again, very broadly, pull data (with SQL, PHP, combination), ( or get it from a URL with javascript), into a data structure, then within a loop in your template, add the dives for each element.
Good reading really depends on which platform you'll be developing this in. There are a bazillion alternatives, including many in Javascript, PHP, Ruby, Python, Go, ASP. Since you mention SQL, you must have some data somewhere (rather than a data service) so you'll need a server-side language, and since you are a beginner, you may want to look into PHP which I think is approachable. Within that there are several PHP frameworks for data, and several for templating, and several with both. Many of the full frameworks (in any language) are geared for experienced web devs. That said, I like the twig templating language for PHP
This, I think, is a good place to start http://www.phptherightway.com along with the super popular but basic W3schools. The link above I think organizes the concept a little better.
You can install the stuff you need on your laptop for that standard (and old school) 'LAMP stack', or use one of the many hosting companies, nearly all of which provide everything you need. good luck learning!
I do not understand why a developer would use Phalcon's Volt template engine.
In the end, after the compilation, the same PHP files are produced, that I would have to write manually in the first place. To me, it looks only to be detrimental to the performance.
Is the answer "so you could pass .volt files to a front-end guy"?
The answer lies in the development of your application. Why do you use a framework instead of pure PHP? Why bother with object oriented programming when procedural/straight PHP is faster?
There are many reasons of course and it is a long discussion. The summary is ease of use and maintainability.
The same goes with Volt. You can use the volt templates to do what it will take you a lot longer if creating plain phtml files (HTML with PHP tags in there). Examples I can give you are template inheritance, partials, calculations within the template (for/each loops) etc.
As far as performance is concerned, there is always a performance hit when using a template engine. Volt luckily is part of Phalcon so the performance hit is minimal since Phalcon does all the hard work in memory instead of using included files here and there to offer its functionality.
The decision is up to you. Volt, Smarty, Twig and others are there to help with development of your application. Your decision is what makes you use the template engine or not.
This is an old question, but I want add some insights.
You asked why you should use Volt, the Phalcon template engine, but in your explanation you want know, more generically, why you should use a template engine. The short answer to your question is: you must use a template engine to avoid mixing PHP with HTML.
But I want answer to the main question also. Why Volt? Volt overload is minimum compared to every other template engines out there and it's not because is written in C, but because it generates a unique PHP file for your view.
Twig is probably the most complete template engine out there. Twig has many more features compared to Volt, it's more stable and older. Twig, anyway, doesn't generate a unique PHP file, but a bunch of PHP classes with methods that call each others. Doesn't matter if you are using the Twig C Extension, Twig is gonna be slow anyway.
Twig is really really slow when compared to Volt and even to the good old Smarty. So, if you are using Phalcon is probably because you want achieve the best performances, serving a lot of page requests; in this case Volt is your friend.
When history of PHP starts, it was standard, that HTML was generated directly inside PHP scripts. But it happen to generate some problems when it grown to one of most popular ever web programming languages.
To keep people working in huge projects comfortable with their tasks ie. when developing web services, where was an MVC architectural pattern invented. M for Model is used to store data and handle them in a maintainable and repeatable manner. V for View as an part, that is responsible to generate proper output. C for Controller that are responsible for sending commands to models etc., being a core logic of application.
When user send a command to service, Controller is handling it and understanding. Triggering changes on proper Models and maybe forwarding actions to other Controllers as long as View Controller is reached. View controller takes a proper view, injects into it generated data and executes it to create output that is send back to user. If template for view is not yet generates, it triggers template engine to do it.
Proper implementation of full MVC greatly helps both programmers, system architects, front-end devs etc. But when on one side it happen difficult to maintain databases (so ORM were developed), on other side of system it was difficult to maintain views.
One of principles of MVC is that Logic (with huge "L") is only in controllers. So there is no logic in views. Using template engine enforces easiness of achieving that because of poor support of logic by them self. It is not a secret, that programmers are "lazy" - so if they have an occasion to put some more advanced logic into view, they would do it.
I guess that all frontend devs have programming skills. Problem is to make them stay with you. Working on huge project with lots of views (and so hudge templates) with PHP mixed into them will drive them crazy. It is much easier to read code written for template engine.
Idea of template engines is to add one more part to system, that offers possibly simple language allowing to use basic logic like loops and if statements. On one side template engine receives kind of a textual file to transform it into PHP file with mixed into it hyper dose of all important HTML.
If you are alone developer, it is important to nobody that you are using files that mixes PHP with HTML. It looks probably close to this:
<html>
<head>
<title><?=$title?></title>
<? foreach($metas as $meta) { ?>
<meta name="<?=$meta['name']?>" content="<?=$meta['content']?>"/>
<? } ?>
But any frontend developer would rather like to work on file looking this way:
<html>
<head>
<title>{{ title }}</title>
{% for meta in metas %}
<meta name="{{ meta.name }}" content="{{ meta.content }}" />
{% endfor %}
for it higher readability. It happens extremely handy when template includes some kind of javascript inlined. After all, you end up with same file you can create by hand, but this file is generated for you and stored, so it is no more generated as long, as core file is not changed. We are generating our templates during deploy what has 0 hit on performance, especially now, when Volt engine is written in C.
Another handy thing about template engines is that (with some your effort) it is possible to generate templates minified on the fly. You wont ever minify your hand-crafted template, except when planning to commit suicide.
So globally, it is a case of:
so you could pass .volt files to a front-end guy
but it is an effect of working in MVC pattern. And Phalcon is made to fulfill MVC principles. I'm not even trying to guess, how you managed to work with this piece of software for ~2.5 years not using template engine. Maybe you are working alone.
Every person has different taste, but i tell you my vision.
I think volt is useful because:
As all phalcon framework, Volt has excelent performance.
Benefits from template engines (i dont wanna repeat that already other answers says)
Hierarchical rendering: More info -> https://docs.phalconphp.com/en/3.0.2/reference/views.html#hierarchical-rendering
I love the phalcon hierarchical rendering, because is clean, easy, and any person can understand where can find the view of something, ideal for a designer, or other non technical person
And to add value, i modify some phalcon parts to apply that hierarchical rendering using app modules, thats all i need.
As an exercise, I intend to replace all front-facing aspects of my Rails application with Backbone.js. Part of the plan includes redesigning everything right down to the CSS.
The issue I'm struggling with is in delegating responsibility for templates and views.
Is there any benefit to implementing the new front-end entirely in Backbone, hence only using Rails as an API?
How do I strike the right balance between Rails and Backbone when it comes to handling the HTML elements of the application?
Since it seems that nobody is going to post an answer to this I'll offer my two cents as just one point of view (I've written elsewhere about the issue of how to get rails and backbone.js to work well together: rails and backbone working together).
Most people in this situation will tend to drop the rails views altogether and migrate everything to backbone.js.
This is what I've done in a project that I'm working on right now.
This is the natural course of events, and particularly once you start getting used to all the complex interesting things you can do with backbone.js and structured javascript, it becomes difficult to turn back and implement standard stateless HTML pages.
As I mentioned in my other answer linked to above; however, there are costs to completely abandoning HTML views and the stateless layer. In my case, I intend to add back pure HTML pages for non-js-enabled browsers for GET requests only once the app has reached a certain level of functionality. We won't support POST or PUT requests unless the user has javascript enabled (or unless they want to go through the JSON API).
That's the balance I've struck: stateless HTML (no-JS) for accessing data, but JS required for posting/changing data. Your choice will vary depending on your use case and target user.
The other thing that I would mention is that if you have been working with rails HTML views on a project for some time, you might be unprepared for the initial overhead required to switch to backbone.js. This is not simply swapping HAML for ERB: you are migrating from a stateless front-end to a stateful one, and that is a potentially huge change (depending on the complexity of the app). I myself was a bit unprepared for the depth of that change, and had to do a lot of catching up before getting our app back on track after making the switch. And we made the switch very early, with minimal functionality already in-place.
Anyway just a few thoughts, hope they help.
I used NetTiers in a number of projects a job or two back. I found it extremely useful for generating back-end interfaces in ASP.NET webforms. The business and data layers were also pretty sweet. I typically use NHibernate, but I think it may be overkill on these particular projects in terms of the time it will take to get running.
Since then, I've been working on projects where practically everything is end-user facing. However, I've recently gotten a side project that will have a lot of back-end administrative stuff and was wondering if NetTiers is still as well-maintained and clean as it was a couple of years back. It doesn't appear to be, but I don't know if that means that it has actually been abandoned or if it has merely been moved elsewhere. Or is there another product (preferably a set of CodeSmith templates) that might work better for me? All I really need is a clean ActiveRecord model that can hit a SQL database on the backend and generate simple user interfaces for CRUD screens for most of my model objects. I need something that will do deep-loading of object graphs kind of like NetTiers will do as well.
Any suggestions?
I'm currently supporting a large NetTiers application and my experience has generally been one of frustration. I inherited the project and took over maintenance of the templates, fixing a number of bugs in the templates and applying some post-generation scripts to the generated files. IMHO the generated code is overly verbose, suffers from massive duplication, and would benefit from more use of generics. The templates I'm working with didn't dispose of resources correctly (the newer template versions may be better). At one point I considered upgrading to a newer version but the size of the exercise put me off. Useful documentation is difficult to find and getting answers to NetTiers questions is not straight forward. The overall impression I have is one of gradual decline.
If you're just after a simple .Net stack for generating a UI from a SQL database I suggest you take a look at ASP.NET MVC3 with MvcScaffolding and Entity Framework. Add AutoMapper and Munq for DI.
We have been using NetTiers for several years now. I think it tend to look overwhelming for first time users, in terms of quantity of stuff generated, and there are a couple of limitations around the DeepLoad functionallity and circularities. I too have the feeling that there have not been many updates lately, but in the overall I've had a great experience using Nettiers with codesmith, and from all the ones I've tried, it's clearly our favorite, with huge productivity gains. We use views, custom sp's, the indexes, etc.
In a comment to another reply: We've tried Automapper, and moved away from it due to the fact that it fails silently when the object's structures change. And moved away from Entity Framework because we don't like hand-coding our DALs. :)
Seaside just released a release candidate for the upcoming 3.0 version, so it appeared on my radar again. As I'm currently pondering what web framework to use for a future project, I wonder whether it's something to consider. Alas, most of the publicity for Seaside is from '07, which is probably one or two generations for the web. So I'm hoping that the community here can answer some questions
Continuation-based frameworks were pretty great when most of your workflow was mostly in HTML, e.g. form submits. For today's JavaScript-heavy environments, that hardly seems worthwhile anymore.
Is Squeak able to handle a reasonable workload? From other questions here and elsewhere, it seems that for proper scaling another implementation (Gemstone etc.) would probably fare better in the long run, but I don't have a proper idea how far away that is. Sessions seem to be rather expensive.
I know that comparisons are hard, but most of the articles you find on the net set Seaside and Rails side by side. How would combinations like Scala/Lift, Clojure/Compojure or Erlang/Nitrogen do instead?
I have answers to question one and two:
This is true. However since version 2.8 Seaside is not a strictly "continuation-based" framework anymore. Seaside uses continuations in the flow module only. Since Seaside 3.0 the flow module is even optional. Also note that Seaside has strong Javascript support since 2005, this is long before mainstream frameworks started to add Javascript functionality. Today Seaside comes with JQuery and JQueryUI support built-in.
Of course that depends on what you store within your session objects, but typically sessions are small (less than 20 KiB). Use the memory profiler in your application to determine the exact memory consumption.
And there is a new seaside book: http://book.seaside.st/book
I find the productivity of working in a Smalltalk IDE with a good set of abstractions outweights all other issues in engineering dominated projects. It works well as an enterprise system for a small company with about 100 (simultaneous, but not heavy) users on a single server (without going to SSD). Since 2007:
Seaside has shown to be able to make the switch from html workflows to javascript ones;
Seaside has been ported to a lot of different Smalltalks;
Has seen Gemstone release GLASS;
The new 'cog' vm with much improved performance has been released a few weeks ago and shows great promise for improved performance.
In Smalltalk we have now three web frameworks to consider, besides Seaside also
Aida/Web and
Iliad.
Both later effectively solve three-like control flow, but without needing continuations. Both also have a very strong Ajax integration, actually you don't realize anymore that you are working with Ajax.
Both also scale in memory consumption well. 10.000 sessions spend 220MB in Aida/Web, that is about 23KB per session, which can be further optimized down to mere 400B per session. This means, that you can run not only but many websites from the single Smalltalk image. Of course you can always upgrade to load balancing solution, when you really need. Which is from my experience very rarely needed.
Comparing to Ruby on Rails, a friend of mine complained that he needs 50MB of memory initially for every webshop site he is selling. He then turned to the Aida/Web solution where he needs about the same MB for the image, but then just few KB for every additional webshop site.
Avi Bryant, the developer of Seaside, said that AJAX triumphs continuations in almost all situations. Nevertheless, you can build reasonably powerful applications with Seaside and AJAX, too.
The Application part of a Web-App can be done in other frameworks quite well using Ajax.
I think a Seaside integrated Smalltalk-to-Javascript Framework like Cappuccino-for-Clamato is missing, currently. I'd like to be able to build real Javascript-Apps using Smalltalk.
Javascript is awesome but being capable of dealing with complicated workflow in a clean cheap way in the server side (as Seaside allows you to) is preventing it to become obsolete. Economy and utility are things that gives return in the short and long run. But telling this in the abstract has no value at all. You should be talking about a precise application and deciding if seaside is part of your bunch of competitive advantages to form an equation that rocks (and knowing why).
About scaling workload with Seaside, the short answer is that you can scale it like hell yah (for the long answer check my answer here: Does Seaside scale?).
too unanswerable man :) rty a variation of what you're really trying to ask
I think the best thing you can do is a prototype of something in a weekend.
If you can do a prototype in two days and you can capture some attention and you enjoyed the developing experience of doing it with seaside then you'll have the foundation of your next thing.
It costs only your time (you can publish in an amazon server).
BTW, this week I've heard about a startup that made its prototype by hand (was everything static and they processed stuff manually). Pretty amazing and crazy and cheap. When they felt that they had enough traction on the idea (which the had) they implemented the app (with whatever tech, I'm sure is no challenge for a seaside developer)