We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
Related
Currently I have a web site full of static pages. This minimizes web server load and guarantees that this site will run even on tiny Linux-based hardware web server.
I am seeking for an ability to make master pages for my site and I like the way used by Ruby on Rails, but this technology is redundant for a simple web site and is too heavy for a simple hardware web server.
I like the SSI, it is really lightweight and cross-platform, but it does not provide master pages, it only makes includes that each document should maintain by oneself.
I like an AJAX technology, but it is client-side dependent.
The IFRAME technology does the opposite to what I want - it references from master page to slave page, and I need the reverse.
Is there something else left?
Template-Toolkit, specifically the wrapper directive, should do the trick.
You can use ttree at build time to generate static pages, avoiding the need for any server side technology beyond a simple HTTPD.
Em.. php includes?
So: CSS, Javascript, Includes directories detailing reusable styling, client scripting, and markup respectively?
There is no way to get any form of master page in the way that you are talking about without server side scripting I'm afraid. The best you can hope for is a JavaScript file that loads other JavaScript files, and external stylesheets (one unusual method I saw was the creation of a universal stylesheet that imported many others - but I didn't see all that much benefit to organisation myself). You could always use iframes... but iframes, as you point out aren't designed for that sort of functionality. That sort of functionality was within the scope of frames, and that had unpleasant results.
If you want to use something like php your server will naturally have to support php, but it is a simple way to produce easy organisation of your pages without having to dive neck deep into a complicated framework like Rails. In my experience adopting a CMS, particularly that developed by somebody else can be more trouble than it's worth.
I have an existing website written in ASP.net, I have recently switched to Mac full time (With Windows in Boot Camp), and need to write a public API for accessing my website's MySQL data. I primarily want to use the API to allow building an iOS application.
I am interested in learning either Ruby on Rails or Node.js, I haven't used either of them yet.
Which language would be better for me to learn?
Rails is a relatively mature web framework based in Ruby and is designed for handling object-mapped data persistence in a relational database backend.
Node.js is much newer on the scene, and unlike Rails, is a more bare-bones package that allows for server-side Javascript applications thanks to a pretty tight HTTP(S) API. Node applications are by nature event-driven, which may or may not be ideal for your application.
Since it seems that you'll need data-persistence (you mentioned accessing MySQL data...), Rails might be easier to get started with, as it comes packaged with all the things you need in this respect and is designed to facilitate this sort of application.
If you you don't really need relational data persistence, Node is probably a better bet as it stays out of your way and lets you decide how to handle things. It's important to note that Node is a much more bare-bones "framework" than Rails -- if you want something slightly higher-level but still lighter than Rails that runs on Node, express is good place to start.
Still, if you want to try Node (I will confess: it's a lot of fun!), it's totally possible to access MySQL in a nice, event-driven (non-blocking) way. Here are two modules that will be helpful:
node-dbslayer
node-mysql
Neither is a language; they're frameworks. There is no "better", there may be a "more suitable" (probably not in this case).
Which would you prefer to develop in, Ruby (Rails), or JavaScript (node.js)?
Would you like to transfer that knowledge to a different job without rampup time (Rails)?
Would you like to learn something a bit more esoteric, event-driven (node.js)? (Ruby has Event Machine, but IMO node.js takes it a bit further.)
So this new application is just a middle man between your ASP.NET thing and your other clients.
In that case, totally use node. Node is great at being networking glue. Node scales great with IO bound applications (i.e. being a network middleman).
If you're going to use node then you probably want to look at express to make it easier.
I was wondering what the advantages/disadvantages of using Microsoft Access would be compared to just creating a custom C# application. Is the execution time the same? Has its time already passed?
C# is a generic development environment designed for producing all applications that can be conceived of.
Access is a development tool specifically designed for one purpose, i.e., creating front ends to databases.
All the components within Access are prebuilt to make interaction with data as easy as possible.
While it is certainly the case that there are libraries and controls available for C# that are designed for the purpose of interacting with databases, there's less integration of the overall development environment for the particular purpose of creating database applications.
Access's database-related components are also more mature than anything that could be developed for C#, since Access has been around twice as long. That also has its disadvantage, as some of the assumptions about how things should work in Access don't work as well in a modern environment (Access was created before the web existed anywhere outside of academia).
I think it's probably OK to choose C# as a development platform for a database application if:
the developers available are already C# whizzes familiar with building database interfaces, AND
you have the need to distribute your app to very large numbers of users.
Access is somewhat difficult to deploy, and in large organizations, when you amortize the savings in RAD over large numbers of desktops, that is quickly dwarfed by the expenses associated with Access deployment issues compared to a self-contained executable with no runtime dependencies.
But we're talking about somewhere well above 100 desktops where the line is crossed (and possibly closer to 500 or 1000), in my opinion.
Access has many plus points if you are dealing with data. One key point to make is to split in your head “Access” (RAD development studio where you make forms reports code etc) and “Jet” the database engine that in bundled with Access.
Access makes a great front end of other database types such as SQL server and you can very quickly make excellent data driven applications very quickly.
You also have an excellent built in reporting suite and easy access to other MS Office applications (sending mail through outlook for example)
Access has picked up somewhat of a bad reputation in IT circles as IT departments have been burnt before by having to support some badly put together application where the original “developer” has long since left. The point is that any language can be used to make a bad application but because more people have access to err access it increases the chances of someone who is not a developer making mistakes!
In my not so humble opinion, the big advantages of MS Access are the low learning curve and the the so much is already done for you. Simple apps can be built by an untrained clerical worker.
That's also one of the biggest disadvantages. MS Access applications are often first started by complete novices and they can get them selves into a lot of trouble. Quite often they get to the point that they are dependant on the app that has been built to do their job, but it needs to be expanded, or has become unmanageable because of some early "decisions" they made they they first started building it (e.g., using some human readable key to reference another table, with no integrity constraints, etc.; and now they have a lot more data than they started with).
Typically by the time that I see it, there's a lot of work to do to undo the previous "developer's" work. And sometimes it'll cost more in time to fix it, than to start over.
Left in the hands of a pro - it's fine for building quick simple apps. Even more complex ones are OK if a pro is doing it. If I had my way, we'd just hand out the runtime version and keep the full version to the IT Pros.
The advantages are the pre-built functionality along with the ability to write custom code when needed. Of course, all of this can be done in C#, it's just not as easy.
The biggest disadvantage to using Access is having at least one answer to every question on SO suggesting using something else. Or better yet, having someone knock Access eventhough they know nothing about it or haven't used it since 2.0.
I'm deciding between LAMP and Google App Engine with Python. Mainly this is an educational experience so I'm weighing the potential ease/quickness of developing on App Engine against the value in learning LAMP from the get go (and not being locked into the App Engine way of doing things
It depends on where you come from. If you're already familiar with either PHP or Python, I'd let my choice depend on that.
If you're starting from scratch, there's a few things to consider :
PHP (if you consider the P in LAMP to be that) has the advantage that there is a huge amount of web applications/sites out there that use it. If you're aim is to be able to modify or contribute to lots of other webapps, I think you should go with PHP. On the other hand PHP is easy to mess up and it is hard to cleanly seperate webdesign and code. PHP has no real application outside of web development that I am aware of (I may be wrong).
Python is a real sweet language with a clean syntax and a lot of (third party) libraries. Python has lots of applications outside of web development.
Google App Engine allows for a clean MVC approach in conjunction with Django (among others). A MVC approach allows to cleanly seperate HTML/CSS/Javascript layout stuff and Python Code.
If you master GAE/Python, it's a small step to go to Django, running on (Linux|Windows)/(Apache|Ningx)/(MySQL|several OtherDB's).
I wrote a prototype for my software in Python as a desktop client-server program, but I want to do the real version as a web service. (I have seen the light? much better deployment and reduced cost) Trouble is, I don't know web development.
I already did something webdev-ish: I have a page with a form on it, that when submitted Apache will run my Python script, which will do some server-side tasks and then send the result on a new page back to the user. Its a very simple tool (doesn't use any DB or framework), but I suppose that's the basic idea of web-based services... I think. To me that was a workaround, I did not realize it is webdev-ish.
So I have a basic idea of how it works, and about 8 years of programming behind me, but I need to learn:
How to design web sites (XHTML and CSS?)
Javascript and AJAX
More advanced features of databases (Postgresql)
I'm thinking Python/Django is a safe bet.
Any suggestions on where to start? I'm not the type who has the patience to read a book; I would rather jump in and build something simple first, then bigger and bigger stuff, but I can't seem to get my head around learning web design - I still format everything with tables.
Cheers and thanks
Check out Django. Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.
There will be a learning curve, but you might as well learn how to do it right the first time. Go through the documentation, and start building small Django applications. There are tutorials on the Django website.
And yes, you will have to learn HTML and CSS anyway.
Tables are not evil, by the way. You don't have to learn your first website with CSS, but you will need to learn correct CSS layout sooner rather than later. There are free CSS templates out there you can use, which makes the correct use of CSS much easier.
I only got slightly into Django, but I hear good things, so stick with it if you like the approach... inheritance & templating language
XHTML blocks just need to not overlap (markup container rule, good XML syntax with contained elements closing before new ones are begun). Honestly the simplest & most common approach to start web layout is PHP, so I suggest that as first alternative since it is so template-centric.
my favorite CMS is ZOPE, built and used with Python for scripting. Zope3 is more like Django, Zope2 I use more still (Python 2.4.x) has some internal syntaxes and methods to grapple with at first, but if you wish to try it I have a basic site editing framework.
the advantage is the object database hierarchy is just like site structure, inheritance of scripts, content objects (HTML chunks & contextual values), properties... so duplication is minimized, the whole site can be a simple template, reuse & extension maximized. navigation scripted, archive by month & listing contents scripted, footer once, sidebar inherited throughout site - override by cloning into subdirs and editing or specifying object/property for local instance closest to the URL path then seeking up to root.
users can have roles in sections, XML-RPC/HTTP/FTP all ZOPE methods including user-defined, so rich clients can workflow media effectively. batch process media uploads with default containers for each item and metadata (filename, type extension) so users get right to their details. ZOPE can host files or static, remote, whichever, so long as the app knows where to find them (one base property for the app or project root)
if you get into Django there is the ZODB standalone library part of ZOPE for persistent storage only, no ORB