I'm new to decorators in java, i've discovered that sitemesh offers a good deal of simplicity and flexibility.I've noticed that the stable version 2 is not much in development(i might be wrong) and that there is a new website for 3 which is still in alpha.My worries is about using alpha code in production.Right now not sure if i will be stuck in 2 because no improvement or use 3 with its risks.
can anyone help? thanks for reading this.
I've been using alpha1 in production for some months now with no problems.
One of the sites has >5000 visits/day.
I only had to tweak the struts upload interceptor because it didn't work out of the box.
EDIT (2014.07.04)
I recently found out that sitemesh 3 is indeed NOT safe for production when used in Tomcat behind an Apache Server with ModJK. See the details here: "Not Modified" header followed by unexpected content body with sitemesh3 and mod-jk
Related
I have got an opportunity to work on a legacy web service project
which has been written 10 to 12 years before . I happily took this
assignment as i really wanted to check out how much effort the
developers had put decades before to write web services without the
advanced framework which we have nowadays . I really think they had
put a lot !!! coz the pkg has so many classes which i dont even
understand what is it ... It has BO ,PO , WSAO classes , CXF mapping ,
marshalling and unmarshalling .. So i want help from senior
developers here who have worked on web services decades before coz i
couldn't find any example in net really , all seems to be archived or
Page not found link .so please provide me any links or examples to
understand JAX-WS 1.2 , Webservice client - service . It might not be
a coding question but a question which would really others who are
willing to work on legacy projects .Thanks in Advance
You might start with just the "spec" jax-ws classes first. Various implementations have a lot of other, non-spec features that aren't portable and go beyond the spec, I'd save those for later. There are parts of jax-ws that are "off the beaten path", (handlers, low level api's, attachments, etc.) you can save those for later too.
This might be a good place to start: https://docs.oracle.com/javaee/6/tutorial/doc/bnayl.html
Java 6 through 8 contains jax-ws (unfortunately it's removed starting with java11) so you don't need an app server to experiment with it, just a java 8 jdk.
This seems to be a pretty good article on using jax-ws with just a jdk:
https://www.javaworld.com/article/3215966/web-services-in-java-se-part-2-creating-soap-web-services.html
The spec, JSR-224, is a good explanation, but it's not light reading, and you have to accept their license.
https://jcp.org/en/jsr/detail?id=224
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have heard many times senior developers asking not to use coldfusion UI tags and that they cause problems. But can someone let me know what kind of problems it creates? I do not use CFML UI tags mostly, but some of the legacy code has them already. So if I have to change them, I need to convince people why they need to be changed. Reasons...
Edit:
I know this has been put on hold, but what I was asking about few points, a list kind of. So when I am talking with someone a client, fellow developer and want to emphasize the reason for not using cfform, I do have those reasons. With lot of good and some not so good answers, I reckon I can put up a list
1) They use old outdated versions of JavaScript libraries and HTML.
2) They have caused security issues in the past.
3) They get in the way of knowing how things actually work.
4) ColdFusion UI does work currently. However, the issue people have is simply, technology changes. It's simple as that really. jQuery and other UIs are constantly changing. Along with a lot of other APIs that ColdFusion UI uses. This means, if you are using ColdFusion 10 today and 5 years from now you are on ColdFusion 13 you may have issues with your ColdFusion 10's UI.
5) Another example is . had an issue recently because it uses google maps and google updated their API. Since the update took place it broke the tag. Since this is a ColdFusion UI and not your own it is difficult to just update the API calls. Which is why it is recommended to use your own. It's a simple fix with jQuery UI but not really ColdFusion UI.
6) Also, a lot of ColdFusion UI messes with your headers. For example, . This tag has been known to break mobile sites and other headers because it adds its own headers to your HTML page.
7) cfinput required="" is conflict with the HTML 5 input required=""
The issues with the UI tags built-in to CF are:
Were written by people who are not CFML developers.
Were written by people who are not HTML/JS developers.
They use old outdated versions of JavaScript libraries and HTML.
They have caused security issues in the past.
They get in the way of knowing how things actually work.
They don't have documentation comparable to the average JS library.
The Flash and XML versions of cfform were especially difficult to work with.
And possibly a few other reasons that have slipped my mind.
If you have old code that uses them, and the code works acceptably, then you're unlikely to get shot for not changing it - assuming there are no further undiscovered security issues, obviously.
(Though of course, whether the code does actually work acceptably or has simply been put up with may be a matter of debate.)
If you're working on new code, you should learn to use modern UI libraries that are written by actual JS developers who understand browsers, libraries that are far more widely tested and documented, that you can understand how they work, that put you in control of what's being done, and so on.
Instead of giving you a link to the solution to a problem that is unknown to #CFML_Developer I will simply briefly explain the issues I've had and other have had with ColdFusion UI.
ColdFusion UI does work currently. However, the issue people have is simply, technology changes. It's simple as that really. jQuery and other UIs are constantly changing. Along with a lot of other APIs that ColdFusion UI uses. This means, if you are using ColdFusion 10 today and 5 years from now you are on ColdFusion 13 you may have issues with your ColdFusion 10's UI.
Another example is <cfmap>. <cfmap> had an issue recently because it uses google maps and google updated their API. Since the update took place it broke the <cfmap>tag. Since this is a ColdFusion UI and not your own it is difficult to just update the API calls. Which is why it is recommended to use your own. It's a simple fix with jQuery UI but not really ColdFusion UI.
Also, a lot of ColdFusion UI messes with your headers. For example, <cfform>. This tag has been known to break mobile sites and other headers because it adds its own headers to your HTML page.
Finally, I personally find all ColdFusion UI more difficult to work with than actual jQuery UI. Just because with jQuery UI you can be specific to your needs and it's a lot more flexible to work with. Honestly, it's also faster to do if you understand jQuery.
How can multiple developers work on the same website (CSS, JavaScript, ASP.NET).
We use SVN as source control, but the problem is more in regards of testing and general workflow.
I know we could do unit tests and we have for our API, but I don't see how we can do unit testing for our frontend?
We get a lot of problems in the frontend like:
Developer 1 changes CSS and it messes up CSS for developer 2.
Developer 1 changes JavaScript and components developer 2 made stops working.
Developer 1 removed an ID or a CSS class in C# (code behind) and CSS styling is lost or JavaScript stops working.
It's basically things of that nature.
What we do now is manually test everything in all major browsers and we spend too much time on that.
Any good suggestions on how we can improve our way of working? Keep in mind that it's a website and we are struggling with problems related to that.
This is a management issue rather than a workflow issue.
You need to be proactive at managing the situation and be tough.
You have a source control system in place, what you need to do is:-
Enforce day end (or more frequent if preferred) check ins.
Rollback work if it doesn't work. You have to be tough on this point to ensure the developers understand that you mean it.
You need to actively communicate the above to your team to make sure they understand the new work procedures.
It'd only take a few weeks for it to sink in, after that you can relax the controls.
Introduce releases/iterations/milestones; and publish them only from the repo.
Can you not possibly break the site areas up into segments and assign developer responsibilities to each, even if it means sandboxing the "base" code of the site (framework / main CSS / main JavaScript) and assigning a specific responsibility to it? You can then task developers to keep their CSS / JavaScript separate from the main files and merge them before testing and release.
We've had similar problems where I work and this approach seemed to sort it out for the most part. For each segment we built we created a new folder in each of the respective projects (DAL / BL / Presentation), based on the functionalities / modules / segments, each with their own site content (JavaScript / CSS), but still making sure that some generic styling and JavaScript being available to all developers.
An official Agile project management methodology (like Scrum) has huge benefits in an environment like this, as you get to discuss these issues on a daily basis and, if over-arching requirements for new CSS and JavaScript are identified by all developers, it can be integrated into the site's base content.
Background:
I have a new site in the design phase and am considering using ColdFusion. The Server is currently set-up with ColdFusion and Python (done for me).
It is my choice on what to use and ColdFusion seems intriguing with the tag concept. Having developed sites in PHP and Python the idea of using a new tool seems fun but I want to make sure it is as easy to use as my other two choices with things like URL beautification and scalability.
Are there any common problems with using ColdFusion in regards to scalability and speed of development?
My other choice is to use Python with WebPy or Django.
ColdFusion 9 with a good framework like Sean Cornfeld's FW/1 has plenty of performance and all the functionality of any modern web server development language. It has some great integration features like exchange server support and excel / pdf support out of the box.
Like all tools it may or may not be the right one for you but the gotchas in terms of scalability will usually be with your code, rarely the platform.
Liberally use memcached or the built in ehache in CF9, be smart about your data access strategy, intelligently chunk returned data and you will be fine performance wise.
My approach with CF lately involves using jQuery extensively for client side logic and using CF for the initial page setup and ajax calls to fill tables. That dramatically cuts down on CF specific code and forces nice logic separation. Plus it cuts the dependency on any one platform (aside from the excellent jQuery library).
To specifically answer your question, if you read the [coldfusion] tags here you will see questions are rarely on speed or scalability, it scales fine. A lot of the questions seem to be on places where CF is a fairly thin layer on another tool like Apache Axis (web services) and ExtJs (cfajax) - neither of which you need to use. You will probably need mod-rewrite or IIS rewrite to hide .cfm
Since you have both ColdFusion and Python available to you already, I would carefully consider exactly what it is you're trying to accomplish.
Do you need a gradual learning curve, newbie-friendly language (easy for someone who knows HTML to learn), great documentation, and lots of features that make normally difficult tasks easy? That sounds like a job for ColdFusion.
That said, once you get the basics of ColdFusion down, it's easy to transition into an Object Oriented approach (as others have noted, there are a plethora of MVC frameworks available: FW/1, ColdBox, Fusebox, Model-Glue, Mach-ii, Lightfront, and the list goes on...), and there are also dependency management (DI/IoC) frameworks (my favorite of which is ColdSpring, modeled after Java's Spring framework), and the ability to do Aspect-Oriented Programming, as well. Lastly, there are also several ORM frameworks (Transfer, Reactor, and DataFaucet, if you're using CF8 or earlier, or add Hibernate to the list in CF9+).
ColdFusion also plays nicely with just about everything else out there. It can load and use .Net assemblies, provides native access to Java classes, and makes creating and/or consuming web services (particularly SOAP, but REST is possible) a piece of cake. (I think it even does com/corba, if you feel like using tech from 1991...)
Unfortunately, I've got no experience with Python, so I can't speak to its strengths. Perhaps a Python developer can shed some light there.
As for url rewrting, (again, as others have noted) that's not really done in the language (though you can fudge it); to get a really nice looking URL you really need either mod_rewrite (which can be done without .htaccess, instead the rules would go into your Apache VHosts config file), or with one of the IIS URL Rewriting products.
The "fudging" I alluded to would be a url like: http://example.com/index.cfm/section/action/?search=foo -- the ".cfm" is in the URL so that the request gets handed from the web server (Apache/IIS) to the Application Server (ColdFusion). To get rid of the ".cfm" in the URL, you really do have to use a URL rewriting tool; there's no way around it.
From two years working with CF, for me the biggest gotchas are:
If you're mainly coding using tags (rather than CFScript) and formatting for readability, be prepared for your output to be filled with whitespace. Unlike other scripting languages, the whitespace between statements are actually sent to the client - so if you're looping over something 100 times and outputting the result, all the linebreaks and tabs in the loop source code will appear 100 times. There are ways around this but it's been a while - I'm sure someone on SO has asked the question before, so a quick search will give you your solution.
Related to the whitespace problem, if you're writing a script to be used with AJAX or Flash and you're trying to send xml; even a single space before the DTD can break some of the more fussy parsing engines (jQuery used to fall over like this - I don't know if it still does and flash was a nightmare). When I first did this I spent hours trying to figure out why what looked like well formed XML was causing my script to die.
The later versions aren't so bad, but I was also working on legacy systems where even quite basic functionality was lacking. Quite often you'll find you need to go hunting for a COM or Java library to do the job for you. Again, though, this is in the earlier versions.
CFAJAX was a heavy, cumbersome beast last time I checked - so don't bother, roll your own.
Other than that, I found CF to be a fun language to work with - it has its idiosyncracies like everything else, but by and large it was mostly headache free and fast to work with.
Hope this helps :)
Cheers
Iain
EDIT: Oh, and for reasons best known to Adobe, if you're running the trial version you'll get a lovely fat HTML comment before all of your output - regardless of whether or not you're actually outputting HTML. And yes, because the comment appears before your DTD, be prepared for some browsers (not looking at any one in particular!) to render it like crap. Again - perhaps they've rethought this in the new version...
EDIT#2: You also mentioned URL Rewriting - where I used to work we did this all the time - no problems. If you're running on Apache, use mod_rewrite, if you're running on IIS buy ISAPI Rewrite 3.
do yourself the favor and check out the CFWheels project. it has the url rewriting support and routes that you're looking for. also as a full stack mvc framework, it comes with it's own orm.
It's been a few years, so my information may be a little out of date, but in my experience:
Pros:
Coldfusion is easy to learn, and quick to get something up and running end-to-end.
Cons:
As with many server-side scripting languages, there is no real separation between persistence logic, business logic, and presentation. All of these are typically interwoven throughout a typical Coldfusion source file. This can mean a lot more work if you want to make changes to the database schema of a mature application, for example.
There are some disciplines that can be followed to make things a little more maintainable; "Fusebox" was one. There may be others.
Let me first say I am aware of this faq for Mach-II, which discusses using application specific mappings as a third option when:
locating the framework in the server root is not possible and
creating a server wide mapping to the Mach-II framework directory is impossible
Using application specific mappings would also work for other ColdFusion frameworks with similar requirements (ColdSpring). Here is my issue however: my (I should say "their") production servers are all running ColdFusion MX7, and application specific mappings were introduced in ColdFusion 8. I most likely will be unable to do option 1 or 2 because they involve creating server wide changes that could conflict with other applications (I don't have a final word on this but I am preparing for that to be the case).
That said, is there anybody out there who was in similar bind and has done an option 4, in any ColdFusion version, or with any similar framework? The only option 4 I can think of is modifying the entire framework to change this hardcoded path, and even if that worked it would be time consuming and risky. I'm fairly sure that if there was a simple modification or other simple solution it would already be included in the framework (maybe it's included in version 1.8 of Mach-II and I don't know about it yet).
Any thoughts on solving this problem or even unorthodox setups with libraries that have specific path requirements would be appreciated. Any thoughts from Team Mach-II would especially appreciated...we're on the same team here Matt! ;-)
EDIT
Apparently, the ColdBox framework includes a refactor.xml ANT task which includes a target that refactors the ColdBox code to use a different absolute path as a base along with several other useful refactoring targets. So problem solved for ColdBox users.
Looking at the build.xml for Mach-II (1.6 and 1.8) I don't see any target in there that would allow me to refactor the code. I thought about creating a feature request ticket for such a task for Mach-II but frankly I don't think creating such an ANT task is a big priority for the MachII team since the need really only relates to either
a) users of ColdFusion versions below 8
b) someone who wants to use multiple Mach-II versions in the same application, a use I doubt they want to support
The ColdSpring code I have doesn't come with any ANT tasks at all, although I do have unit tests, and I bet if I poked around the SVN I'd find a few build scripts.
Using Ant tasks to refactor and retest the code, or the simpler (and sort of cop out) solution of creating a separate ColdFusion instance for the application are the best answers I've been able to come up with. I don't need this application to exist in the shared scope of other applications, so my first solution is going to be to try and get a dedicated CF instance for this application.
I'm also going to look at the ColdBox refactor.xml ANT task however and see if I can modify it to work generically to recognize and refactor CFC references with modified absolute paths. If I complete this task I'll be sure to post the code somewhere and edit create an answer to link to it. If anybody else wants to take a crack at that or help me out with it feel free.
Until then I'll leave this question open and see if someone comes up with a better solution.
Fusebox is not so strict, I think.
In XML mode (maybe I call this not 100% correcly, just mean using the Application.cfm) it's just proper include in index.cfm, something like:
<cfinclude template="fusebox5/fusebox5.cfm" />
In non-XML mode it will need proper extending in the root Application.cfc:
<cfcomponent extends="path.to.fusebox5.Application" output="false">
All you need is to know the path.
Perhaps you could create a symbolic link and let the operating system resolve the issue for you?
I've been playing with FW/1 lately, and while it may look like you need to add a mapping and extend org.corfield.framework, you can actually move the framework.cfc file into your web root and just extend="framework". It's dead simple, and gets you straight into a great framework with no mess and very little overhead.
It should be as simple as dropping the 'MachII' folder at the root of your domain (i.e. example.com/MachII). No mappings are required to use Mach-II if you just deploy at the root of the domain of your website.
Also:
Please file a ticket for the ANT task you mentioned in your question. Team Mach-II would love to have this issue logged:
Enter a new ticket on the Mach-II Trac
If you want to tackle an ANT task for us, we can get stuff like this incorporated into the builds faster than waiting to for a Team member to work on the ticket. Code submissions from the community are welcome and appreciated.
We don't keep an eye on Stack Overflow very often so we invite you to join our official community group at called "Mach-II for ColdFusion" at Google Groups. The Google Group is the best place to ask questions or comments like this if you want feedback from the Team.