Besides the obvious differences between JavaScript and Java, what are the relevant differences in using either SmartClient or SmartGWT?
SmartGWT is the GWT wrapper for SmartClient, which, as you say, means that you're able to write your SmartGWT app using java.
From my experience the only difference that matters when you're programming is that the GWT wrapper is a bit more restrictive than using the js components directly. For example, programmatically scrolling a TreeGrid from java is hell, since the body of the underlying table (that you need to get at in order to scroll the blasted thing) is not exposed through SmartGWT, while it of course is easily reachable from js.
Overall I wouldn't base the choice between the js components and the gwt wrapper soley on these differences, but I would look at other factors in your project. Which techniques are you most comfortable with? How much custimization are you planning on doing?
In my case, code maintainability.
We are a Python house. But for client-side code we opt for GWT, initially with GXT, but now with SmartGWT.
We don't like Java, but we don't like JS much more, Order, maintain libraries for several widgets, extends objects to give custom functionality, etc. between doing this in JS or Java, the option was obvious, Java side. We write reusable components here, and now we write very minimal code for client side, only reuse components and use REST to comunicate with ours Python backends.
We know that SmartGWT is more verbose than SmartClient, but, with Netbeans autocompletion (some coleagues here use Eclipse) we have direct access to every method, documented, instead to go to the showcase or google every time that we need to test and try new functionality.
SmartGWT provides you the advantage that you may use powerful editors.
You can debug your own code easily (however it's not very helpful for diving into the smartclient code itself).
You have all the auto completion stuff of eclipse/netbeans at hand. When starting to work with SmartClient/Gwt it helps you find the things you are looking for because the editor can list you classes or the available methods and some basic documentation what the class/method actually does. Saves you a lot of time crawling through the docs
Banang : API's to access ListGrid / TreeGrid body are now exposed in Smart GWT.
We chose to use Javascript (no SmartGWT) ... I prefer it that way, although some of our team members (newer to Javascript) would have preferred the SmartGWT way. Both have their pros and cons :
One of the advantages of using SmartGWT, is that you get to have compile time errors since everything gets compiled first by the Java compiler, before it gets rendered to Javascript.
One of the drawbacks of SmartGWT, is that it doesn't expose the full underlying Javascript Smartclient API. This means, if you want to do more advanced stuff, you might end up needing to do it in Javascript anyways.
Another drawback of SmartGWT, productivity wise, is that every single change you do and want to test, needs to go thru the painful Java EE compile/deploy process, whereas if you do it in Javascript, you can alter client side code faster by changing .js files directly without the need for the whole compile/deploy process.
SmartGWT is based on java code and when compiled it transforms it into java script, is a
heavy since it transforms java code into js
SmartClient is a framework based on js, you can use its components in an xml page and you manipulate them in Js, and it’s light
le showcase de smartclient
I recommend smartClient
Related
I'm starting to study Dart. It seems a nice language and in some aspects a real improvement over JavaScript. Since it claims to come with "batteries included" and to be meant for "structured web apps", though, I fail to understand how to actually structure a web app with it. Almost all the tutorials concentrate on language features, but Dart is quite simple and with many familiar bits, so that's the easy part.
Recently I fell in love with AngularJs. Now routing, two way binding, nested scope, clean separation of concerns... This actually means "structured" to me. But all the Dart examples I find are about selecting HTML elements and attaching listeners to them. This is old-style jQuery-like web programming and quite frankly the opposite of what I think of when I read "structured".
I don't want to compare a language and a framework and I know that Angular Dart is out, but I fear I'm missing something of vanilla Dart, because if it's all about a shorter syntax for lambdas, class based OOP vs prototypical OOP and the like, I don't see how it's supposed to be a game changer: there are many other languages that provide an alternative JS syntax (à la CoffeeScript) and compile to it, and they don't come at the price of losing a perfect integration with existing JavaScript libraries and tools.
Sure, it has optional static typing, which may be great, but this comes more to a matter of preferences. I'm a full time Python and Ruby developer and I'm perfectly fine with dynamic languages. Is this what they mean by "structured"?
Thanks for any clarification that will eventually come.
I work on AngularDart and have some experience structuring web apps.
When building a web app in Dart you would pick a web app framework, for example AngularDart or polymer.dart. Web app frameworks have a lot of opinion which is something that doesn't fit in the core libraries. In that respect, "vanilla Dart" is fairly vanilla.
Since I'm most familiar with Angular, I'll discuss the Angular + Dart combination. However, the rest of this post is also true for polymer.dart.
Angular provides a lot of structure to your app. We've been able to provide a similar structure for both Dart and Javascript. The concept of directives, data binding and dependency injection exist in both.
Dart provides more structure and we've been able to use that structure while building AngularDart. e.g. the directive API is defined in terms of annotations which means that IDEs understand them and can help you code.
There are a number of "structure" features in Dart. One of my favourites is tooling. With types and annotations comes better tooling support.
Types in Dart are most useful when combined with tools. Auto-complete is great but for large web projects, static analyze is even better. For example, in AngularDart, since directives are annotated classes, we can assert that the annotation is correct. Even more interesting is the potential to build tools. In AngularDart, we have a tool that extracts and analyzes all directives. This type of tooling is possible in Javascript but easy and supported by the language in Dart.
libraries, packages
integrated dependency management with pub package manager
class based instead of prototype based
scopes of variables as one would expect in a modern language
static syntax check
better tooling support like code completion
I'm currently starting to integrate "Delphi Web Script" in my application basically only as a scripting engine (interfacing with functions, classes, etc.); awesome software for the standard delphi open source quality in my opinion, but just for curiosity,
What's exactly the "web part" of the project?
How is intended to be used?
It was used somewhere with some success commercially?
Thanks!
As ain said, the original use was for PHP-like, ASP-like server-side web-page generation, but it was also capable of general purpose use, which is what I used it for. And as I did not use the "web" side of DWScript, most of the "web-oriented" features haven't been ported over (only the HTML Filter was ported actually).
The Web functionality is still available in the SourceForge repository, if someone wants to tackle the port. Though, they may be outdated beyond simple renamed methods and classes, as since DWSII, the script engine has gained various features. For instance, it is now capable of multiple thread-safe executions of a single compiled script, while the old codebase is built around the limitation that a compiled script can be executed by only one thread at a time.
On the other hand, there are some new features that could simplify the porting, the simple WebServer demo recently added uses RTTI to expose TWebResponse & TWebRequest f.i. (was manually exposed in DWSII). On the down side, that's only possible with recent Delphi versions.
AFAIK the main focus of the original author of this scripting engine was to make it possible to embed Pascal scripts into HTML pages, just like ie PHP does it. Hence the name "Delphi Web Script". While the focus of the current maintainer, Eric Grange, is on using it as a general purpose scripting engine, it should still be possible to use it for web purposes as well - for that you use the "filters" feature of the library. Check out the dwsHtmlFilter unit for HTML filter.
Yesterday I saw a presentation on Java Server Faces 2.0 which looked truly impressive, even though I am currently a happy ASP.NET MVC / jQuery developer. What I liked most about JSF was the huge amount of AJAX-Enabled UI components which seem to make development much faster than with ASP.NET MVC, especially on AJAX-heavy sites. Integration testing looked very nice too.
Since the presentation only emphasized the advantages of JSF, I'd like to hear about the other side as well.
So my questions are:
What are the main disadvantages of Java Server Faces 2.0?
What might make a JSF developer consider using ASP.NET MVC instead of JSF?
JSF 2.0 disadvantages? Honestly, apart from the relative steep learning curve when you don't have a solid background knowledge about basic Web Development (HTML/CSS/JS, server side versus client side, etc) and the basic Java Servlet API (request/response/session, forwarding/redirecting, etc), no serious disadvantages comes to mind. JSF in its current release still needs to get rid of the negative image it gained during the early ages, during which there were several serious disadvantages.
JSF 1.0 (March 2004)
This was the initial release. It was cluttered with bugs in both the core and performance areas you don't want to know about. Your webapplication didn't always work as you'd intuitively expect. You as developer would run hard away crying.
JSF 1.1 (May 2004)
This was the bugfix release. The performance was still not much improved. There was also one major disadvantage: you can't inline HTML in the JSF page flawlessly. All plain vanilla HTML get rendered before the JSF component tree. You need to wrap all plain vanilla in <f:verbatim> tags so that they get included in the JSF component tree. Although this was as per the specification, this has received a lot of criticism. See also a.o. JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?
JSF 1.2 (May 2006)
This was the first release of the new JSF development team lead by Ryan Lubke. The new team did a lot of great work. There were also changes in the spec. The major change was the improvement of the view handling. This not only fully detached JSF from JSP, so one could use a different view technology than JSP, but it also allowed developers to inline plain vanilla HTML in the JSF page without hassling with <f:verbatim> tags. Another major focus of the new team was improving the performance. During the lifetime of the Sun JSF Reference Implementation 1.2 (which was codenamed Mojarra since build 1.2_08, around 2008), practically every build got shipped with (major) performance improvements next to the usual (minor) bugfixes.
The only serious disadvantage of JSF 1.x (including 1.2) is the lack of a scope in between the request and session scope, the so-called conversation scope. This forced developers to hassle with hidden input elements, unnecessary DB queries and/or abusing the session scope whenever one want to retain the initial model data in the subsequent request in order to successfully process validations, conversions, model changes and action invocations in the more complex webapplications. The pain could be softened by adopting a 3rd party library which retains the necessary data in the subsequent request like MyFaces Tomahawk <t:saveState> component, JBoss Seam conversation scope and MyFaces Orchestra conversation framework.
Another disadvantage for HTML/CSS purists is that JSF uses the colon : as ID separator character to ensure uniqueness of the HTML element id in the generated HTML output, especially when a component is reused more than once in the view (templating, iterating components, etc). Because this is an illegal character in CSS identifiers, you would need to use the \ to escape the colon in CSS selectors, resulting in ugly and odd-looking selectors like #formId\:fieldId {} or even #formId\3A fieldId {}. See also How to use JSF generated HTML element ID with colon ":" in CSS selectors? However, if you're not a purist, read also By default, JSF generates unusable ids, which are incompatible with css part of web standards.
Also, JSF 1.x didn't ship with Ajax facilities out of the box. Not really a technical disadvantage, but due to the Web 2.0 hype during that period, it became a functional disadvantage. Exadel was early to introduce Ajax4jsf, which was thoroughly developed during the years and became the core part of JBoss RichFaces component library. Another component libraries were shipped with builtin Ajax powers as well, the well known one being ICEfaces.
About halfway the JSF 1.2 lifetime, a new XML based view technology was introduced: Facelets. This offered enormous advantages above JSP, especially in the area of templating.
JSF 2.0 (June 2009)
This was the second major release, with Ajax as buzzword. There were a lot of technical and functional changes. JSP is replaced by Facelets as the default view technology and Facelets was expanded with capabilities to create custom components using pure XML (the so-called composite components). See also Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
Ajax powers were introduced in flavor of the <f:ajax> component which has much similarities with Ajax4jsf. Annotations and convention-over-configuration enhancements were introduced to kill the verbose faces-config.xml file as much as possible. Also, the default naming container ID separator character : became configurable, so HTML/CSS purists could breathe relieved. All you need to do is to define it as init-param in web.xml with the name javax.faces.SEPARATOR_CHAR and ensuring that you aren't using the character yourself anywhere in client ID's, such as -.
Last but not least, a new scope was introduced, the view scope. It eliminated another major JSF 1.x disadvantage as described before. You just declare the bean #ViewScoped to enable the conversation scope without hassling all ways to retain the data in subsequent (conversational) requests. A #ViewScoped bean will live as long as you're subsequently submitting and navigating to the same view (independently of the opened browser tab/window!), either synchronously or asynchronously (Ajax). See also Difference between View and Request scope in managed beans and How to choose the right bean scope?
Although practically all disadvantages of JSF 1.x were eliminated, there are JSF 2.0 specific bugs which might become a showstopper. The #ViewScoped fails in tag handlers due to a chicken-egg issue in partial state saving. This is fixed in JSF 2.2 and backported in Mojarra 2.1.18. Also passing custom attributes like the HTML5 data-xxx is not supported. This is fixed in JSF 2.2 by new passthrough elements/attributes feature. Further the JSF implementation Mojarra has its own set of issues. Relatively a lot of them are related to the sometimes unintuitive behaviour of <ui:repeat>, the new partial state saving implementation and the poorly implemented flash scope. Most of them are fixed in a Mojarra 2.2.x version.
Around the JSF 2.0 time, PrimeFaces was introduced, based on jQuery and jQuery UI. It became the most popular JSF component library.
JSF 2.2 (May 2013)
With the introduction of JSF 2.2, HTML5 was used as buzzword even though this was technically just supported in all older JSF versions. See also JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used. Most important new JSF 2.2 feature is the support for custom component attributes, hereby opening a world of possibilities, such as custom tableless radio button groups.
Apart from implementation specific bugs and some "annoying little things" such as inability to inject an EJB in a validator/converter (already fixed in JSF 2.3), there are not really major disadvantages in the JSF 2.2 specification.
Component based MVC vs Request based MVC
Some may opt that the major disadvantage of JSF is that it allows very little fine-grained control over the generated HTML/CSS/JS. That's not JSF's own, that's just because it's a component based MVC framework, not a request (action) based MVC framework. If a high degree of controlling the HTML/CSS/JS is your major requirement when considering a MVC framework, then you should already not be looking at a component based MVC framework, but at a request based MVC framework like Spring MVC. You only need to take into account that you'll have to write all that HTML/CSS/JS boilerplate yourself. See also Difference between Request MVC and Component MVC.
See also:
What is the difference between JSF, Servlet and JSP? (just to understand the basics)
Using JSF to develop tableless CSS layouts (another myth about JSF)
JSF vs plain HTML/CSS/JS/jQuery (when JSF is the wrong choice)
Design patterns in web applications (illustrates the ideology behind MVC)
After 5 years of working with JSF, I think that I can add my 2 cents.
Two major JSF drawbacks:
Big learning curve. JSF is complex, that's just true.
Its component nature. Component-based framework tries to hide the true nature of the Web, which comes with a huge amount of complications and disasters (like not supporting GET in JSF within almost 5 years).
IMHO hiding HTTP Request/Response from the developer is an enormous mistake. From my experience, every component-based framework adds abstraction to the Web development, and that abstraction results in unnecessary overhead and higher complexity.
And minor drawbacks that come to my mind:
By default ID of the object is composed of its parents' ids, for example form1:button1.
No easy way to comment-out incorrect page's fragment. Tag <ui:remove> needs syntactically correct content which is parsed anyway.
Low quality 3rd party components which e.g. don't check isRendered() inside processXxx() method before continuing.
Incorporating LESS & Sencha is hard.
Doesn't play well with REST.
Not so easy for UX designers, because ready-to-use components have their own CSS styles, that need to be overwritten.
Don't get me wrong. As a component framework JSF in version 2 is really good, but it's still component-based, and always will be...
Please take a look at the low popularity of Tapestry, Wicket and low enthusiasm of experienced JSF developers (what is even more meaningful).
And for contrast, take a look at the success of Rails, Grails, Django, Play! Framework - they all are action-based and don't try to hide from the programmer true request/response and stateless nature of the web.
For me it's major JSF disadvantage. IMHO JSF can suits some type of applications (intranet, forms-intensive), but for real-life web application it's not a good way to go.
Hope it helps somebody with his/her choices that regards to front-end.
A few drawbacks that pop to mind:
JSF is a component-based framework.
This has inherent restrictions that
have to do with obeying the
component-model.
AFAIK JSF supports only POST, so if you want a GET somewhere you have
to do a plain servlet/JSP.
Most components try to provide abstractions over domains like
relational databases and front-end
JavaScript, and many time these
abstractions are "leaky" and very hard to debug.
These abstractions might be a good starting point for a junior developer or someone not comfortable with a particular domain (e.g. front-end JavaScript), but are very hard to optimise for performance, since there are several layers involved, and most people that use them have little understanding of what is going on under the hood.
The templating mechanisms that are usually used with JSF have nothing to do with how web desigers work. The WYSIWYG editors for JSF are primitive and in any case, your designer will give you HTML/CSS that you'll have to spend ages converting.
Things like EL expressions are not statically checked and both the compiler and IDEs are not doing a good job at finding errors, so you'll end up with errors that you'll have to catch at run-time. This might be fine for dynamically typed language like Ruby or PHP, but if I have to withstand the sheer bloat of the Java ecosystem, I demand typing for my templates.
To sum up: The time you will save with JSF, from avoiding to write the JSP/servlet/bean boilerplate code, you'll spent it x10 to make it scale and do exactly what you want it to do.
To me the biggest disadvantage of JSF 2.0 is the learning curve not only of JSF, but the component libraries that you have to use in order to get it to do useful work. Consider the staggering number of specifications and standards you have deal with to really be proficient:
HTML in the various incarnations. Don't pretend you don't need to know it.
HTTP -- when you can't figure out what is going on you have to open Firebug and see. For that you need to know this.
CSS -- Like it or not. It isn't so bad really and there are some nice tools out there at least.
XML -- JSF will probably the first place you use namespaces to this degree.
Servlet Specification. Sooner or later you will get into calling methods in this package. Aside from that you have to know how your Facelets gets turned into XHTML or whatever.
JSP (mostly so you know why you don't need it in JSF)
JSTL (again, mostly to cope with legacy framework)
Expression Language (EL) in its various forms.
ECMAScript, JavaScript, or whatever else you want to call it.
JSON -- you should know this even if you don't use it.
AJAX. I would say JSF 2.0 does a decent job of hiding this from you but you still need to know what is going on.
The DOM. And how a browser uses it. See ECMAScript.
DOM Events -- a topic all by itself.
Java Persistence Architecture (JPA) that is if you want your app to have any back end data base.
Java itself.
JSEE while you are at it.
The Context Dependency Injection specification (CDI) and how it clashes with and is used with JSF 2.0
JQuery -- I would like to see you get along without it.
Now, once you are done with that you can get on with the proprietary specifications, namely the component libraries and provider libraries you will pick up along the way:
PrimeFaces (my component library of choice)
RichFaces
MyFaces
ICEFaces
EclipseLink (my JPA Provider)
Hibernate
Weld
And don't forget the container! And all those configuration files:
GlassFish (2, 3, etc)
JBoss
Tomcat
So -- THIS IS MAKING IT EASY? Sure, JSF 2.0 is "easy" as long as all you want to do is the most basic web pages with the simplest interactions.
Simply put, JSF 2.0 is the most complicated and cumbersome mishmash of glued together technologies as exists in the software universe today. And I can't think of anything I would rather use.
Inexperienced developers usually will create applications that are painfully slow and code will be really ugly and hard to maintain. Its deceptively simple to start, but actually requires some investment in learning if you want to write good programs.
At least at the start you will often "stuck" on some problem and will spend more time reading balusc posts on internet than actually working :) After a while it will be less and less of that, but it still can be annoying.
Even more annoying when you find out that the problem is not due to you lack of knowledge/mistake but actually a bug. Mojarra was(is?) quite buggy, and another layer of components adds even more problems. Richfaces was biggest piece of crap software ever written :) Don't know how it is now on version 4. We have Primefaces which is better, but still you will run into bugs or lack of features especially with more exotic components. And now you will need to pay for Primefaces updates. So I would say its buggy but its getting better especially after 2.2 version fixed some problems with spec. Framework getting more mature but still far from perfect (maybe myfaces better?).
I don't find it especially flexible. Often if you need something very very customized and there are no components that does that - it will be a bit painful. Again I'm talking from average developer perspective - the one with deadlines, quick reading tutorials, and searching stackoverflow when getting stuck because no time to learn how it really works :) Often some components seems to have "almost" what you need, but not exactly and sometimes you might spend too much time to make it do something you want :) Need to be careful in evaluating if its better to create your own or torture existing component. Actually if you are creating something really unique I would not recommend JSF.
So in short my drawbacks would be: Complexity, Not very smooth development progress, buggy, inflexible.
Of course there are advantages too, but that's not what you asked. Anyway that's my experience with framework others might have different opinions, so best way is to just try it for a while to see if its for you (just something more complex - not naive examples - JSF really shines there:) IMHO best use case for JSF is business applications, like CRMs etc...
"JSF will output View-layer HTML and JavaScript that you cannot control or change without going into Controller code."
Actually JSF gives you the flexibility, you can either use standard/third-party components or create your own which you have full control over what is rendered. It is just one xhtml you need to create your custom components with JSF 2.0.
We developed a sample project with JSF (It was a three week research so we may have lose some things!)
We try to use core jsf, if a component is needed we used PrimeFaces.
The project was a web site with navigation. Each page should be loaded via ajax when the menu is clicked.
The site has two usecases:
A page with a grid. The grid is loaded via ajax and should support sort and paging
A three step wizard page. Each page has client side validation (for simple validations) and server side ajax base validation (for complex validations). Any server exception ( from service layer) should be displayed on the same page of wizard without navigating to next page.
We found that:
You need to use some hacks from omniFaces to make the JSF view state fixed. The JSF state will be corrupted when you include pages via ajax in each other. This seems a bug in JSF and may be fixed on next releases (not in 2.3).
The JSF Flow is not working correctly with ajax (or we could not make it work!) We try to use primeface wizard component instead but the client validation seems not supported and mean while it was not standard JSF flow standard.
When using some jQuery components like jqGird, and you need to load JSON results, then you are advised to use pure servlet, The JSF will do nothing for you. So if you use these kind of components, your design will not fit in JSF.
We try to do some client scripts when ajax complete by ajaxComplete and we found that the PF 4 has implemented its own ajax events. We had some jQuery components and we need to change their code.
If you change the above sample to a non Ajax project ( or at least less ajax project) you will not face lots of above issues.
We summarize our research as:
JSF is not working well in an fully ajax base website.
Of course we find lots of nice features in JSF which may be very helpful in some projects, so consider your project needs.
Please refer to JSF technical documents to review JSF advantages, and in my opinion the biggest advantage of JSF, is the COMPLETE AND HUGE support from #BalusC ;-)
I'm not a Java Server Faces expert at all. But IMHO the main disadvantage is that it's server side. I'm tired of learning and using server side web presentation layer frameworks like ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php frameworks and ruby on rails frameworks. I said goodbye to all of them, and I said hello to Angularjs and TypeScript. My presentation layer runs on the browser. I doesn't matter if it is served by Windows IIS running php or ASP.NET, or if it is served by an Apache web server running on Linux. I just need to learn just one framework that works everywhere.
Just my two cents.
For me the biggest shortcoming of JSF is poor support for programmatically (dynamically) generated pages.
If you want to construct your page (create page component model) dynamically from java code. For example if you are working on WYSIWYG web page constructor. Adequate documentation of this use case in not generally available. There are many points where you have to experiment and development is quiet slow. Many things just don't work how you would expect. But generally its possible hack it somehow.
Good thing is that it's not problem in philosophy or architecture of JSF. It's simply not elaborated enough (as far as I know).
JSF 2 brought Composite Components which should make component development easy, but their support for dynamic (programmatic) construction is very poor. If you overcome quiet complicated and almost undocumented process of dynamic Composite Component construction, you will find out that If you nest few Composite components little deeper, they stop working, throwing some exceptions.
But It seems that JSF community is aware of this shortcomings. They are working on this as you can see from these two bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599
Situation should be better with JSF 2.2 at least if we are talking about specification.
Commenting on my last few months of Primefaces/JSF experience:
If you can use components "off the shelf", I guess it's not terrible.
However, it doesn't play well as soon as you step outside and need custom UIs. - For example, we needed to use Twitter's bootstrap for our project. (Not primefaces bootstrap).
Now our pages work as follows:
Page loads.
User interacts with a Primefaces that has ajax functionality
Bootstrap's javascript bindings break
We run extra javascript to rebind everything
The promise of JSF to avoid writing javascript turned into writing more javascript than we would have if not using Primefaces--and that javascript to is fix what Primefaces breaks.
It's a time sink--unless you again use "off the shelf" stuff. Also really ugly (Primefaces) when having to work with Selenium. It can all be done--but again--there's only so much time.
Definitely avoid this if you're working with a UX/design team and need to rapidly iterate on the UI--you can save time by learning jquery/writing straight HTML--or looking at react/angular.
JSF has many advantages, question being on disadvantage let me add couple of points on it.
On a practical scenario of implementing a web project with in a time frame you need to keep an eye on the following factors.
Do you have enough senior members in your team who can suggest best
controls suitable for each scenario?
Do you have the bandwidth to accommodate the initial learning curve?
Do you have enough expertise in your team who can review the JSF
stuff produces by the developers?
If your answer is 'No' for the questions, you may end up in a non-maintainable codebase.
JSF has only one disadvantage: before starting "JSF" development you should clearly understand web development, core java and front-end architecture.
Nowadays "new" JavaScript frameworks just try to copy/paste "JSF" component-based model.
Among all the "mainstream" frameworks such as Spring MVC, Wicket, Tapestry, etc., the JSF of Java EE with its composite components is the most elaborated presentation-layer and component-oriented technology provided. It is a bit cumbersome and incomplete compared to solutions provided by HybridJava.
I'm working on Windows XP/Delphi 7. I need to add some procedures (or functions) inside a program that is running, and I do not want to re-compile it once again after I finished it.
I just have a host application with 5 functions to send different types of alarms, but there are other new alarm types, so I have to do new functions to send those alarms, but I should not re-build the host application. I have a class named TAlarmManager that it's invoked calling those functions.
Maybe a plugin?? OK, but how can I "insert" new functions??? Tutorial, manual, book, etc.. for learning about this, or any advice on how to do this???
I have studied plugins (I'm totally new on this theme), but no one "talks" about adding functions to a host application. It seems to me that plugins add functionality from itself, I mean, they have been developed with self code to do something, not to "add" code to the host application... How can I do this??
For the technical side: How does the Delphi IDE do it? That would be the first place for me to look.
To understand plugins, you must understand that you can't add new functions. You could but since the old code doesn't know how to call it, they wouldn't be called.
So what you do is you add a "register" or "start" function to your plugin. That start function gets a data structure as parameter which it can examine or extend. In your case, that would be the list of alarms. Alarms always work the same (my guess), so it can add additional alarms.
The main code will then, after registering all plugins, just walk over the list of alarms and invoke the standard alarm function on each of them. It no longer cares where each alarm comes from and what it really does.
The key here: You need to define an interface which both sides subscribe to. The main code calls the interface functions and your plugin code implements them.
Another option available is to use a scripting component to your project. One which works quite well is PascalScript. This would allow you to load external scripts after the fact and then run them as needed to interact with your application. As Aaron suggested you will also need to still provide an interface of some sort for your script to interact with your application.
See also Plugins system for Delphi application - bpl vs dll? here on Stackoverflow.
I'm not quite sure what you mean by "alarms", so I'm making a couple of assumptions.
1) If you don't need additional code for the alarms, I would try to make them data driven. Keep the different kinds of alarms in a database or configuration file, which makes it easy to update applications in the field without recompiling or reinstalling.
2) If you need special code for each alarm, you could use run time packages as plug-ins for your application. Search for Delphi runtime packages to get some ideas and tutorials. Here are a couple of links I found:
http://delphi.wikia.com/wiki/Creating_Packages
http://delphi.about.com/od/objectpascalide/a/bpl_vs_dll.htm
3) Scripting, as skamradt already mentioned. If it makes sense for your application, this could also let your customers write their own add-on functionality without requiring a recompile on your part.
You almost definitely want to use Pascalscript, as skamradt suggests. You should start here, and seriously consider this option. There are many possibilities that come out of being able to serialize live code as text. The only downside is possibly speed of execution, but that may not matter for your application domain. I would have upvoted skamradt, but I don't have enough reputation to upvote :)
Some time ago I was looking at a situation sort of like what you're describing.
My answer was .DLLs. I put the variable code in a .DLL that was dynamically loaded, the name specified in a configuration file. I passed in a record containing everything I knew about the situation.
In my case there was only a success/fail return and no screen output, this worked quite well. (It was commanding a piece of machinery.)
This sounds like a place where a scripting language or "Domain Specific Language" may make sense. There are several approaches to this:
Implement alarm functions in VBscript (.vbs files written in notepad) that accesses your Delphi code via COM API. Using the COM API gives you access to a large range of programming tools for writing functions, including Delphi. This is the most clumsy solution, but easiest to do. It may also be a benefit to your sales process, and it is always good to think about how to sell things.
Implement your own function language in Delphi. This way you can make it so easy, that your endusers can write their own alarm functions. If you do it as an expression evaluator, you can write an alarm as 2*T1>T2. There are several expression evaluators out there, and you can also write your own if they don't match your needs.
Use a predefined programming language inside your Delphi application, for instance, "Pascal Script", see http://www.remobjects.com/ps.aspx
You should take a look at PaxCompiler, like PascalScript it allows to load scripts, but you can even precompile them before for more performance. Look at the demos section for the solution of your problem.
As a side note, the web page really looks bad, but the package is really powerful and stable.
I think that the scripting solution it's good for this situation.
There are many scripting packages that you can evaluate:
Context Scripting Suite
Fast Script
RemObjects Pascal Script
TMS Scripter Studio
paxScript
Other packages that you can find on Torry, DSP, VClComponents,...
Regards.
I want to streamline the process by which I create static websites.
I want to avoid having to do multiple editing operations when I have to change one page element, like the text or image in a footer.
I want to be able to use my tool on a local computer, in order to upload the resulting structure to my server.
I don't want to use a tool that is required to reside on a server. I simply don't want a php solution when I don't need it's power or want it's overhead.
I certainly don't want to use a CMS.
Ideally, I would like the solution to be well-documented.
I've looked at the perl template toolkit. But is capable of so much, that it's body of documentation effectively hides the simple tasks that I want to accomplish.
I've also looked at webgen, but the same problem exists. It can do so much that it is difficult to set up for the simple task of creating a small static website. Again, the documentation is very detailed, but unhelpful for the creation of simple sites.
What solutions do other developers use ?
The most obvious solution is to use an editor like Dreamweaver that has templating built in. The result of template + page content is a single static page that's served as plain HTML. The page processing is done at design time, not when the page is served. It's been a number of years since I've used DW but I'd guess it still offers this feature. Frontpage might support this as well, but I've barely used it so I couldn't tell you.
Another, more creative solution would be to make a scripted site using Perl or something and then mirror it with wget. The mirrored copy will just contain the HTML that was generated from your scripted pages. That way, you get (some of) the flexibility of scripting while still getting the performance and simplicity of serving static HTML.
It all depends on the language you're using... HTML is prolly not the best, but if you're using ASP.NET then you can use Masterpages. If you're using PHP or ASP you could include headers and footers, as well as navigation and other persistent content.
This is not so much a tool as it is a concept.
If you don't want to use any server side solutions and you don't want to use ASP.NET then your only real option is iFrames but they do have some issues with SEO so I would stay away from them.
Honestly, I would suggest ASP.NET. Just use Mono. It is open source and can run on Apache and a couple other *nix server types. It will allow you to use user controls and masterpages to manage your code and reduce code duplication. I know that will create some server side overhead but .NET does compile its code on the server. Also, it wouldn't be doing much on the code side just putting your html files together which something is going to have to do regardless. That would mean pretty minimal processing on the server.
I know you said no server-sided solutions but mod_layout for apache does what you want pretty easily.
http://freshmeat.net/projects/mod_layout/
Adobe's Contribute tool can let you do this too -- it's kind of like Dreamweaver for people who don't want to know about HTML. Perfect for the situation where a company chooses someone to maintain a website that has never done anything on the web beyond casual surfing (why does this happen so much?). It uses FTP/SFTP in the background.
That said, if you have any developer bones in you, you will be highly annoyed by the way it shields you from the code. Also, getting any help from Adobe is a lost cause.
There is Ristretto project: https://github.com/ViliamKopecky/Ristretto. It's designed for simple creation of HTML files. It uses templating from Nette Framework (PHP), but is produces plain HTML, so you don't need PHP on server.
It also allows you to keep variables aside from files in Neon format (Yaml-like).