Now that we're on a cf10 server, I'm exploring the cfscript syntax with all my pet projects.
For example: my base template for all my pages could potentially change from:
<cfinclude template="/Inc/html.cfm">
<cfinclude template="/Inc/body.cfm">
Hello World!
<cfinclude template="/Inc/foot.cfm">
<cfinclude template="/Inc/End.cfm">
to:
<cfscript>
include "/Inc/html.cfm";
include "/Inc/body.cfm";
WriteOutput("Hello World!");
include "/Inc/foot.cfm";
include "/Inc/End.cfm";
</cfscript>
So I'm concerned about what I don't know. For instance, if I starting using the script syntax for all my new work, am I limiting myself to not using Railo in the future?
So far, I've used Adobe ColdFusion and Microsoft SQL Server exclusively, but I'm going to be giving a talk at iccm.org in a few months and I'm sure the audience will want to know about Railo and mySQL as alternatives.
What corner am I painting myself into if I start using cfscript syntax?
No, you are not limiting yourself to not using Railo in the future. I have come across very very few incompatibilities - one trivial one I can think of - with ColdFusion in Railo's CFScript implementation.
Railo on the whole strive for cross-compatibility with ColdFusion with their CFML, and they generally only veer away (by design) when the ColdFusion way is just wrong in any sensible way of measuring such things. But even then, generally Railo has a "warts and all" approach.
As there's not really much to CFScript, and the functionality of control structures is fairly "pre-determined" (eg: there's only really one interpretation of how an include statement can work), I don't see this becoming a problem.
Railo's version of CFscript is much more advanced/developed and far more developer friendly and nice to play with, however it'll also run your coldfusion cfscript fine, if there is any issues it'll be small.
I recommend only using cfscript in cfc's and in view .cfm files use cfml, thats where it looks good, other languages try for all kinds of templating engines eg. php has twig, smarty etc, however cfml in views in just perfect, however its nasty in cfcs once you get used to writing purely cfscript all the time you'll not only find cfml repulsive you'll be able to jump between other languages much easier
I don't think you will run into issues using cfscript in Adobe ColdFusion versus Railo. As Adam mentioned, Railo tries to stay compatible with Adobe as much as possible. However, my issue with cfscript is that not all tags are supported. So as soon as you need to use one of the unsupported tags then you have to break out of cfscript, write your tag based code, and then start cfscript again. It is functional but ugly if you have to do this. I have been trying to write more and more of my code in cfcs and can typically write those using cfscript syntax. However, I find that in my main templates I still use the tag based syntax more often.
Here is a page that lists the supported tags in cfscript for Adobe ColdFusion: What is supported in CFScript
Related
I need to get my Meteor JSapp in more than one language.
What would be the best approach for i18n?
Google passed my quite a bit of results but reading them I am more confused than happy. There a many hacks but is there a settled solution to this?
This is more a comment than an answer (however my repu still is too low :o):
Localization normally is only needed client side (there are exceptions but not many and they can be dealt with) and as Meteor is quite young with an own templating engine it's normal that you find more hacks than stable solutions.
However you can doge that bullet by using an older client side templating technique than Meteors built in one like AngularJS with Angular-Meteor (http://angularjs.meteor.com/). Personally I can just recommend this project as it gives you a lot more power than Blaze alone does. And now when you look for solutions for localizing AngularJS you will find a lot more. One I can recommend is angular-gettext (https://angular-gettext.rocketeer.be/) which also comes with a grunt script to extract and compile your strings in one click and which builts a .pot file so that you can translate your app with PoEdit just like you would with an old school webapplication. The only thing you may need to do yourself is to extend the grunt script to parse for any custom translation functions you may add (but maybe you can live without those than you wouldn't need to do anything).
Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.
Recently our newest web designer asked me why we use ASP.NET for our website. Reading through his question to the real one, I started thinking about it myself. Why are we using ASP.NET for web development?
The problem we find so far is colaboration between the design team and developers. Typically our designers create some snazzy cool look crayon laced web pages, then show them off for approval in all their glory. Once approved, the developers rip the HTML out and shove it in to ASP master and detail pages, and huzzah! out comes pretty website.
Since Dreamweaver doesn't play nice with Visual Studio, this is the same process for even small tweaks and changes. I would prefer to just write the backend and let the designers draw the pretty pictures and fancy CSS. Our current websites have plenty of reason to use ASP on nearly every page, so I can't do half in HTML, the other half in ASP.
I have no aversion to doing something else, another language, CMS platform, some other random buzzword, etc...
What are your experiences with this design situation? Are we doing it the hard way? Should we consider alternate platforms and languages? Are there any good, proven ways to allow designers to work on ASP (while still using Dreamweaver)?
Start learning Asp.net MVC as soon as possible. Designers will love you for that. :) And you'll be up to date with new development technologies that will also make your solutions much more robust and less complicated.
But otherwise. Designers should be able to read XHTML fluently. Learning asp.net semantics shouldn't be too hard. Then give then Visual Studio where they can manipulate content. As long as they know how asp.net web forms work things should be fine. They'll probably be able to do majority of things using just CSS. I know I can. Sometimes I do have to check resulting HTML, but it works.
Aside from Wicket (a java web framework), I don't know of any framework or language that would allow designers to continue to work on the design once developers have started to add logic to it.
I would suggest two things though:
Use a MVC framework - ASP.NET MVC, Ruby on Rails, Django, etc since this allows for far more separation of presentation and logic
Keep your presentation layer as stupid as possible and use helpers as much as possible or even better, put the logic in the domain objects. The view should only show or get data with absolutely no logic for processing data, this will keep the pages much more designer friendly.
I find your question very interesting because no matter what kind of technology the project uses the interfaces between the different roles will always cause some friction. I am not sure if there is a technological solution to this communication issue because the designer and developer speak literally different languages.
Depending on the skillset of your designers and developers an additional layer might help you out. I do not know how ASPX works but i am sure there will equivalents to the concepts of other technologies.
In case you have mainly static content which can be expressed in XML than you could provide the backend which delivers the content in XML with a defined Schema and your designers could describe the transformation in XHTML and CSS via XSLT. Given that your designer are capable using XHTML and CSS the addtional effort to learn XML and XSLT is not that huge. I find this solution much powerful than template languages which try to emulate the richness of the serverside scripting language in their own limited constructs. In case you have dynamic elements on the clientside like DHTML, AJAX or you name it you could define your own xml tags which are transformed to richer client side objects after the designer did their work. I guess the designer will understand the usage of these special tags and you provide the proper translation into client side objects.
I used this approach with some coworkes based on PHP. PHP was only the driver for the transformation. The content was assembled into xml with special tags which were transformed into XHTML and CSS via XSLT. Once the objects and the transformation for the different objects is defined you build up a library which can help to shorten the developement cycle of new pages of you webapplication. The benefit of the extra work is, that you designer can change the layout of the page without ever touching you server side code.
Maybe this helps.
Consider using either Expression Web or SharePoint Designer. The latter is now free.
I know you specify dreamweaver, but have you looked at Blend? It plays very nice with Visual Studio and is quite a nice app. to work with.
i know vb.net, but have had no experience at all with web programming. i need to make a web app that can run in a browser where there is a board game and pieces that you can move around. can someone help me get started? are there any examples in asp.net?
i need something like this:
http://www.hallofbrightcarvings.com/game/grid
i don't know what language this is built in, but i would much prefer vb.net. i would like the pieces to be pictures instead of text. please help get started.
I have a very basic example of moving pieces around a grid written in javascript.
You can see it in action here and if you take a look at the source you can see it's done with jquery mostly. Feel free to take a prod around, I haven't updated that version in a long time but hopefully you might find it useful.
I think ASP.NET can do very little for you according to what you described. What you need is either Flash or Javascript skills.
Let's decompose this, you need two things if you want to make the whole thing yourself
Client Side: Flash, SilverLight, JAVA
Server Side:PHP, ASP.net, Java
As you know vb.net and want to work with asp.net, so I recommand to use Silverlight.
How complex can this be?
Depends on what you want to build, if you want to build a Mafia war games, then you'll need to work the user interface and it'll be very hard. Also the server side will be important as you need to handle registration and relation between different players.
If you specify more your question, you could get better answers.
The example you cited above is fully client-side, which means the code all sits on the browser and the server doesn't do anything to enable the grid. So if you did a "Save As" of that page on your computer, you could run it offline.
You should use the view source functionality of your browser on the page you cited, and look at how it's built. It's done using HTML, CSS and javascript. Use w3schools to get yourself started on those three matters.
If you really need to code it using vb.net, I don't know of any way that allows drag-and-drop for web forms. I'd be interested to know though. Ajax and .net drag-and-drop should be keywords for you to look into.
To do this on the web, you'd probably want to divide the project into two components: Client-side and server-side.
On the server-side, you'll want to use language like PHP, Python or ASP.NET. I think ASP.NET has some way to use VB.NET, so that would be a good choice for you to minimize the number of new things you need to learn.
Client-side is going to be the big hurdle. There's basically two different approaches to take here:
HTML+CSS+Javascript, using HTTP callbacks (ie, AJAX) to communicate with the server.
Flash using Flex (I think HTTP calls is probably the easiest way to talk to your server here as well.)
For a game like that, I would think that Flash is probably the best way to go. It will be easier to do graphics and sounds, and it'll run the same in every browser that has Flash support.
I know Microsoft has made efforts in the direction of semantic and cross-browser compliant XHTML and CSS, but it still seems like a PitA to pull off elegant markup. I've downloaded and tweaked the CSS Friendly Adapters and all that. But I still find myself frustrated with bloated and unattractive code.
Is elegant, semantic CSS with ASP.Net still a pipe dream? Or is it finally possible, I just need more practice?
The easiest way to generate elegant HTML and CSS is to use MVC framework, where you have much more control over HTML generation than with Web Forms.
See this question for more discussion, including use of MVC. This site uses ASP.NET and the markup is pretty clean. Check out the HTML/CSS on MicrosoftPDC.com (a site I'm working on) - it uses ASP.NET webforms, but we're designing with clean markup as a priority.
As long as you use the Visual Studio designer, it's probably a pipe dream. I write all of my ASP.NET code (all markup, and CSS) by hand, simply to avoid the designer. Later versions of Visual Studio have gotten much better at not mangling your .aspx/.ascx files, but they're still far from perfect.
A better question is: is it really worth it? I write web applications and rarely does the elegance of the resulting HTML/CSS/JavaScript add anything to the end goal. If your end goal is to have people do a "view source" on your stuff and admire it, then maybe this is important and worth all of the effort, but I doubt it.
If you need the semantics, use XML for your data. I do believe in the idea of the semantic web, but my applications don't need to have anything to do with it.
As DannySmurf said, hand building is the way to go.
That said, you might look at Expression Web. At least it is pretty accurate in how it renders the pages.
#JasonBunting - Yes, it's absolutely worth it. Semantic and cross-browser markup means that search engines have an easier (and thus higher rankings) time with your content, that browsers have an easier (and thus less error-prone) time parsing your content for display, and that future developers have an easier time maintaining your code.
Yes - it's a pipe dream. Since working with a professional web designer on a joint project who HATED the output of ASP.net server side controls I stopped using them. I essentially had to write ASP.net apps like you would write a modern PHP app. If you have a heavy business layer then your page or UI code can be minimal.
I've never looked back since. The extra time spent writing everything custom has saved me a great deal of time trying to make Visual Studio / ASP.net play nice with CSS/XHTML.
i can't believe nobody has mentioned css adapters. many of the common controls used in asp.net (gridview and treeview for example) can be processed through an adapter to change the resulting html that is outputted to the browser.
if going the mvc route isn't a viable option, it is possible to write your own adapters for any of the built in asp.net controls.
http://www.asp.net/CssAdapters/