I have a large Adobe ColdFusion 9 site that uses the no XML version of Fusebox 5.5. The site does not currently use CFCs in the model. The choices have been narrowed down to either CFWheels, Coldbox, or FW/1. My question is, which of those three would be faster and easier to convert to when moving from a Fusebox no XML site?
Thank you
Ease of conversion is the wrong question. Conversion is a one-time event.
Maintenance is an on-going situation, and is a far more important factor to base your decision on.
Investigate your shortlist - they all come with sample applications - and determine which one you'd rather work with going forward, then do what it takes to convert - none of the three should be especially difficult.
(Though I've only dabbled with cfWheels and ColdBox, so can't guarantee there isn't some hidden gotchas that make them more complicated to convert, but again if they're easier for your team to work with, that's more important.)
Related
I have been searching the web for this information and I think I need some help with understanding this better.
I would like to learn how to write back-end of a web application in C++ and essentially how to output C++ to web pages and make it talk to a MySQL database. For the record I can write decent code in C++ but I never did it for web.
Wherever I go on the web and find people asking about this the first list of responses is WHY would you when yo have scripting languages. I am aware of the scripting languages, I have used them for years but I am running across cases where this is a requirement and I would like to learn more about it.
My intent it to write an app that uses Angularjs on the front and C++ on the back. I am a fairly well versed PHP developer and I might take this task on by writing PHP initially but I do need to account for a possibility of rewriting in C++ and this makes me think I should probably write it in C++ from the get go.
I understand that the most usual question is WHY I would use C++ instead of a scripting language so I will try and give a limited set of reasons. Please do understand I am not a pro in this aspect of C++ yet and I am evaluating the situation I am in.
So here are some of my reasons...
The project I am about to take on is bound to be very resource intensive and I would really like to gain all the speed I can possibly get from the get go. The more control I have over the app process the better. Essentially I need precision, I know and love C++ and it allows me to retain the control to a great degree..
The group of people I am talking to in the context of the project are aware of the advantages of C++ fro the resources and speed perspective and they hold a portion of the investment bag which gives them a vote in how the project will be approached. Time IS on my side, but i want to waste as little of it as possible.
I am comfortable with C++, have a C++ oriented mind and would love to use it in this context as much as possible.
So I guess my questions are...
Is there a good tutorial that can take me from the basics to
something intermediate?
How do I write a web site backend in C++?
How do I write C++ to work with MySQL on Linux.
Is there a way to do this on Linux servers?
(I believe Facebook it doing it).
I found this http://www.compileonline.com/compile_cpp_online.php on http://www.compileonline.com and it is giving me hope but I need more information to know how to get there.
I am aware that I am not asking an example code based question but I often find good reference posts on Stack that answer these types of questions so I hope someone can help me. I feel a bit lost here.
My preferred approach to building angular apps is to use the back-end pretty much strictly as a REST server.
Here are a few places that list options:
I'm searching a cgi lib in C to build a restful web service
and
How popular is C++ for making websites/web applications?
and
https://softwareengineering.stackexchange.com/questions/147445/how-does-one-interface-c-with-the-web-at-google-for-example
One option that seems to come up multiple times is http://cppcms.com/. Also http://www.webtoolkit.eu
Integrating angular will be pretty much the same as integrating with any other back-end. If you're using the back-end as a REST server you can pretty much statically serve all of the angular code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I found around 8 Strenghts and flaws of using APEX over another program(http://en.wikipedia.org/wiki/Oracle_Application_Express), but i am not sure i quite understand WHEN to use it.
From what i understand, if you want a fast and easy-to-use development tool related to Oracle, Apex is your first choice. While if you need a complex solution, APEX won't fit.
I would like to know you guys opinion on this. In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented. We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates.
Apex is free, and an oracle XE database is free too. Apex is rapid development.
But what you're asking depends on so much more.
From what i understand, if you want a fast and easy-to-use development
tool related to Oracle, Apex is your first choice.
Is an oracle database already being used?
Easy to use dev tool: yes, sure. But as with anything, it depends on whether you have some experience with it, what the specs and expectations are, ...
While if you need a complex solution, APEX won't fit.
Well,... Would a complex solution be so much less complex in another environment? Just how complex are we thinking? In my opinion, you can go pretty far in apex and adapt it to your needs. it might involve creating templates and plugins to set up a framework, but it is doable. An example would be apex projects whom have been completely integrated with ExtJS. Apex is not the answer to everything too, but it's good. If you'd stay within the Oracle stack for more involved/complex, i'd say the next thing is ADF. Personally, i'm not convinced by that one though. It also has its pros and cons (such as: requiring java knowledge. pro for some, con for others...)
In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented.
How large is this club? How intense will the website be used?
Is there a DB already? Is it Oracle?
Who has DBA knowledge (even basic)?
Who will develop?
If your specs are up to spec, then much fiddling shouldn't be necessary after the launch.
We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates
Who will host the server? Who will run it? Who will administrate it? Do you plan to go cloud-based?
I'd almost ventured to suggest PHP may be a good alternative if this is a small project. Those developers may be easier to find and less expensive than an apex/oracle developer. But then again, if you're planning to outsource it may be less of an issue. If your oracle instance would be in the cloud somewhere, you'd even be pretty safe i'd believe...
Really, what options are you trying to compare? You're asking about apex, do you have any experience with it?
Honestly, your question is not so much a question as it is an opener to a discussion. Each technology and database will have its pro's and cons, fans and dislikers.
Personally, i really like apex. It has a lot going for it, especially when you're already invested in the Oracle stack. And it is still growing, getting good support, and great releases with lots of new features.
I can't really say how it must be set up a (reliable) service from the ground up: server and database, doesn't matter how small, you'll need some understanding and knowledge for that. If you just wing it and cross your fingers, you'll burn them somewhere down the line. Same with development. But as far as i'm concerned that goes for any other tech. Unless you outsource those aspects of course.
Etc etc. There is much and more to be discussed this way.
I put a downvote there for these reasons: there is much to be discussed, it isn't really much of a question which has a conclusive answer. And it maybe only could fetch a conclusive answer if you put more specifications up there and get people of the concurrent platforms to respond.
Edit
I'd like to react on Daniel's post.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
I'm a developer too, and i don't do server and database administration (corporate environment). Not that i haven't dabbled a bit here and there in my spare time, but i digress.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
So speaking as a PHP developer, would you even recommend PHP to achieve this? Would it be less or just as complex?
I'd also argue about complexity. I've worked on some large forms, which for me by now means there are more than your average amount of items, some dynamic actions, validations, maybe some custom process(es). I've not encountered extremely complex situations and honestly i'd question who created those expectations. Thinking outside the box may be a virtue at times, but that doesn't mean the box is always bad. Complex mechanisms or pages can maybe be broken down into more easily accomplishable parts. An example would be using modal pages to break it up.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms.
I agree about limited programming experience: you'll only create the most basic forms and reports, and having almost no experience i'd think you'd shy away from even option pages in fear of breaking something. Same thing goes for even basic db and server administration: i wouldn't like to rely on such a person when there is no experienced backup (but a very small project as is apperently being described might be acceptable).
I too am only invested in the programming side.
It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
I'd say that the templates make things very flexible and are certainly not hard to use
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Wow. I strongly disagree with this. I've maybe encountered one such thing over the course of a year and tons of forms. Not that i haven't heard of some problems on the OTN forums, but usually they had to do with upgrades.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
It is too bad that there are not that many large, public sites which use apex out there. As far as i'm aware, there are and have been large project involving apex, but those usually are in a corporate environment and thus are never shown off (can't be). I personally believe apex can be pushed a lot further than the basic forms+reports you mention (and i mean basic, because things will usually come down to forms+reports in this context).
Debugging does not have to be a pain though. If you provide enough debug messages and comments in your own code, that will help a great deal. Debugging the page, javascript console, and if needs be an autonomous error logging procedure to be used in your plsql packages,... I'd say there is plenty to help out (and if you're driven to this, you are working on some more complex material, and i assume that you have the knowledge to actually deal with the complexity you've set up).
And interesting point you raise lastly is maintenance though. I'd say a point on which apex should improve a lot is versioning, out of the box. Exports need to be improved so they can be broken up a lot easier.
Wow, look at that wall of text... I could've guessed this would turn out into a discussion.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
To start we created a few applications, just to get a feeling. Afterwards we started with the easy parts of the application. APEX is really great if you only have to build some reports and forms to edit the entries of the database. It's very fast to create these things with the integrated wizards.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms. It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
I am posting here as a guest--hopefully, I will create an account. I used O-HTML-DB from its early releases. We built pretty fine apps. I last used it in 2004, having moved to non-development roles.
Since 2007 though, I decided to revisit the tool and found out about APEX. I have since had my own test apps. I disagree with most of what the intern says.
If you have a limited objective (your business need and associated requirements), then your use of APEX will be limited. This is a very robust application, with sophisticated security features (I have been in InfoSec/Cyber since 2009.
Yes, you are correct than claims about APEX not requiring a solid development background are not accurate. You need to have a sound grasp of SQL/PL/SQL, JavaScript. But you c an also take great advantage of OTN, where developers generously share their know-how. When I started with O-HTML-DB, I had never built a DA in a business environment before. I had theoretical SQL skills. I was a Web Developer with a grasp of JavaScrip, training in Java from Learning Tree International (in addition to academics). But I and my colleague (we were two developers) learned a great deal from OTN. We built three Web apps, one of which supported over 6,000 users--just O-HTML-DB!
APEX has taken O-HTML-DB to new dimensions. You do not need to hard-code validations like we did with O-HTML-DB. Of course, you can modify, which requires a sound grasp of SQL/PL/SQL.
Maybe templating is somewhat confusing to many developers, understandably. But as you continue to "play" with APEX, I am sure you'll like it. It can do nearly anything. Only your limited vision will restrict it.
Erick
While learning Sitecore I have found that the majority of Sitecore sample code on the web is in XSL instead of .NET.
What would be the advantage of choosing XSL over the processes I have become accustomed to as a .NET developer?
Are there processing speed advantages to using XSL?
Is XSL actually easier once you are comfortable with the syntax?
I'll just add my 2 cents too:
I find that there are too many limitations in XSLT that need to be overcome with either external "libraries" or with you developing a method in C# that can be used in XSLT.
So I find using Asp.Net simpler. But then I'm also a lot better with Asp.Net than with XSLT.
But XSLT has some good things:
good when getting fields from the current context item
good with simple content etc.
doesn't force the solution to recycle/rebuild
usually a nice way it fails, ie. the page still works, but the xslt that failed says it fails
When I first started working with Sitecore, my company used quite a bit of XSLT, but we've slowly gone away from that, because of it's limitations and because most people here are more familiar with Asp.Net/C#.
Some folks prefer XSL because of existing team skill set, the availability of XSL talent, or the belief that XSL is easier or cheaper to learn.
In Sitecore, ASP.NET-based sublayouts actually perform much better than XSL renderings. If that's what you are comfortable with, go for it. I've never created an XSL rendering myself.
XSLT is a powerful language; its main advantages over languages like ASP.NET tend to come when you want to reuse and customize logic over a wide variety of different pages or different source document structures with common shared elements and other variable structures. To achieve this it uses a rule-based processing model which some people find quite difficult to get to grips with on first encounter. Learning it is an investment that will pay off over time, but it can be daunting at first.
As for performance, I've never come across a site where it isn't fast enough for the job, and that includes some pretty high-stress services; when people have had performance problems they've usually turned out to be in other parts of the processing pipeline (or simply due to bad coding).
The choice between XSLT and .Net components in Sitecore is largely one of taste and skillset. XSLT in Sitecore does have some drawbacks though - it tends to be outperformed by .NET components for all but the most simple renderings and the places where it might seem most logical to use it, such as replicating content tree structure as a site menu, are actually those that tend to take the biggest performance hit. In the right situations XSLT is an incredibly powerful tool and well worth learning, but I've yet to see a convincing argument for making much use of it in Sitecore. It's also worth noting that some of the standard patterns of XSLT programming aren't the most efficient in Sitecore.
The only real advantage I can think of, would be that XSLT renderings are easier to deploy in isolation. Say, for instance, that you're updating your "News Spots" rendering and you want to deploy this change to test/production right away - it would be a simple case of uploading the .xsl file itself.
Using .NET development (and enduring the Web Application Project model), a deployment of the code base would implicitly deploy any and all changes to the affected assemblies - including whatever work you have in progress.
There are, of course, ways you can manage this. Source code branching/merging and so on - but that's an additional layer of complexity to your solution.
That being said, I use .NET for well over 95% of all my Sitecore development myself :-)
"In summary, a primary goal of software design and coding is conquering complexity. The motivation behind many programming practices is to reduce a program's complexity. Reducing complexity is a key to being an effective programmer." -Steve McConnell (1993)
Let that guide when to use XSLT over C#.
We have a medium sized ColdFusion code base for our Intranet and Website. For most of the history of the code we have used hard coded links in the cfm's for where to go and for what 'save' code to tun.
In the last few years we've began using cfc's to handle more of the "navigational" code as well as more automated save code (implicitly calling the save process for a given cfc on init)
Assuming that it makes sense to begin using a framework, is it better to begin using it for newer projects or attempt a full scale conversion?
EDIT
To avoid confusion, I'm sensing that by moving to more cfc based code we are going down the path of accidentally creating our own framework. It seems to me that taking a proactive step toward using a proper framework and allowing the cfc's to process data is probably a wiser choice.
I'd only put the effort into a conversion if you were spending more than 10-20% of your time maintaining the project. (Your threshold my be lower or higher.) Other than that, use it just for new projects.
Why? I think the conversion is going to be painful, laborious and potentially a waste of valuable time.
"Assuming that it makes sense to begin
using a framework, is it better to
begin using it for newer projects or
attempt a full scale conversion?"
I would say that the biggest criteria for whether you should move to a framework are:
Am I spending a good amount of time maintaining current code, and is it difficult?
Am I repeating a lot of code? Do you find yourself writing a lot of the same thing over and over when adding to the current project?
Depending on how large the application is, it might be worth it to convert a current application to a framework if it saves you more time down the road by making maintenance easier and reducing code repetition for future additions to the current project. If you rarely maintenance the application except for a few tweaks here and there, then I would say leave it alone and use a framework only for new applications.
Frameworks have a short term cost and a long term gain.
When we start out without one we usually start building one over time indirectly to increase re-use of code, and make things more structured..
I have been a big fan of Fusebox, probably because I've just used it for so long.
What I have done in the past is, if I know the site will never be updated in into any real website functions, I just roll my own cfswitch to navigate between actions. each action I simply break down into the dsp act qry type files fusebox likes.
If ever I need to put it into fusebox, most of my circuits and actions are already done. The path forward is a bit easier.
On the other hand, if I know the client may want more in the future, I will just put it in a framework and leave it at that.
On a sidenote, I have also been checking out the very impressive ColdBox -- which seems to have some fantastic support, scalability and very well documented is cfc intensive... check them out too..
Have you considered using a framework such as fusebox instead of rolling your own? If you begin using a framework on new projects you might then find it easier to apply what you've learnt to existing projects.
This is related to this question:
how-can-i-port-a-legacy-java-j2ee-website-to-a-modern-scripting-language
but with a narrower focus.
We're pretty much rewriting our legacy Java app from the ground up for a variety of reasons, but attempting to keep the user interface pretty much the same.
In one of the answers, someone said:
Pick representative pages and rework them into the appropriate templates. You might make use of some legacy JSP pages. However, don't waste too much time with this. Use the HTML to create Django templates.
The thing is, the application has about 15 different "front pages", each of which is largely composed of an appropriately mixed&matched subset of ~100 jsp files. I believe the partitioning of content in the jsp files is probably the partitioning that I would want to use for the Django templates; thus I'd rather convert them to templates than start with the HTML and re-do the work of figuring out the proper partitioning.
So, I'm really hoping there is a reasonable way to do this conversion.
I'm a Django newbie & have never worked with javascript (tho other folks on my team have), so any help would be greatly appreciated: if you can recommend an automated or semi-automated tool, or suggest a basic approach, tips & tricks, advice, horror stories..
Thanks in advance!
Edited in response to Vinay's answer:
I think it is fairly vanilla jsp, with no third party libraries involved.
There are scriptlets, but they are well-segregated into their own files.
At this point I think we want something quick that we can improve
to best-practices later.
Regarding EXTENDS versus INCLUDE, this makes me think that we ought to
think carefully about the design of our front pages, at least; but can
take a least-effort approach to converting some of these small snippets.
You might be on a hiding to nothing - it'll certainly depend a lot on the details, e.g. your use of third-party libraries and custom JSP tags. Do you just want to implement it in Django with minimal work, or do you want the finished site to reflect Django best practices? For example, in Django it's common practice to design templates using their extends feature - although Django does have an include tag which is analogous to <jsp:include/>, one sees extends more often and include much less often. In the JSP world, the extends functionality is not part of vanilla JSP and is implemented using third-party libraries e.g. SiteMesh or Tiles.
If I were faced with the task of "get something that works - fast!", my first approach would be to work up a Python script which parsed all the JSP files (using a fairly unsophisticated parser based on regular expressions) and spat out the equivalent Django template files, flagging up the hard stuff as it goes. It probably won't be pretty and it won't do everything well, but it'll be systematic and you'll get a checklist to things which need to be done by hand (e.g. template tags which need to be implemented). The likelihood of this approach adding value is proportional to how tidy and systematic the JSP code is, whether you use scriptlets at all, and so on.