Can anyone provide links to any resources that break down the default template for the TFS2010 build process (DefaultTemplate.xaml) into it's constituent components and what they do. I know how to navigate around the workflow designer in VS2010 but to be honest it just reminds me of a huge VB6 procedural function - amazingly difficult to learn / follow when you're just starting out.
Paul - The "Customize your build process" section on MSDN is probably the most informative source for learning about the components of the build template. The build default template consists of activities that can be found in the Microsoft.TeamFoundation.Build.Workflow assembly, thus you can also learn about the activities and their properties on MSDN.
I agree that the build default template is humongous and the learning curve is quite steep. For now, one of our developers who actually has worked with customizing the build process a lot offered the following suggestions to improve the experience (#1 and #3 should help you directly in working with the default template):
Apply the hotfix
Refactor your process template into custom activities to reduce the size of the workflow file
Use tfpt buildprocesstemplate /clean to remove the designer “junk” from the XAML to make diff easier.
Related
I want to use some ASP.NET based CMS for creating my website and don't know which to choose...
I begin it in Sitefinity, but with it very hard to manage code as you want... And it generates ASP.NET WebForms code...
Now I heard about Orchard, which is CMS developed by some Microsoft employers, and is ASP.NET MVC 3 based...
Now I have some questions about that
What advantages have Sitefinity against Orchard?
Is there any issues and bugs with using Orchard? Is it comfortable
to use?
If you have any other suggestions about using other CMS, I will be pleased)))
full disclosure: I work for telerik, the company that makes Sitefinity, but these opinions are based on my own experiences with both platforms.
as is often the case, it really depends on a) your needs b) your environment and c) your abilities
Sitefinity is uses asp.net webforms so indeed that is the paradigm behind its pages and controls. This has the advantage that if you are experience with ASP.NET, you've already got a lot of the skills needed to customize and extend Sitefinity. Templates are simply master pages, widgets are simply ascx user controls, and themes are standard asp.net themes.
Orchard follows a parallel of this approach, but as you said, in the MVC world. It makes use of views, layouts, controllers, and other mvc patterns as its foundation. If you're strong with asp.net MVC, it can be a pretty solid platform.
As Mystere Man pointed out, it is relatively new CMS, and I might add seems to be mostly community based. When trying to figure things out in a project I was working on, I felt like I was at the mercy of whatever developer created that one component of the platform and whenver he or she had time to respond.
On the other hand, one of the many advantages of going with Sitefinity is the excellent support you get from Telerik, as well as an active community forum.
Sitefinity is also ramping up its release schedule, with major point releases coming three times a year as well as service packs in between to improve performance and constantly add new features, always based on feedback from customers.
Ultimately, it is always going to come down to your own experience and what is a best fit for all people involved. A site can have any number of involved people, from developers to designers to content writers and of course your visitors. Try each product and think about how each role will interact with the system, and see which feature set best aligns with your needs on all fronts.
hope this was helpful!
No fully featured CMS is going to be "easy" to program. They might have easy modes that let you color inside the lines, but as soon as you want to do something they didn't account for it gets very hard.
Orchard is a fine CMS, although it's not as mature as many others. You can create your own MVC based sites to go inside it. However, extending Orchard beyond the trivial becomes complex quickly (althought you can do a lot with the trivial).
It's extremely simple to install and use. I'd suggest doing it and playing around with it, also look at the developer pages on the web site.
I have only worked with Sitefinity 3.7. To be honest, and even despite the support from Telerik, I found it extremely difficult to use, once you went beyond the basics.
As regards Orchard, I agree wholeheartedly with Josh that the support is the big issue. Bertrand Le Roy will answer your questions once a day on Stackoverflow, sometimes very briefly. Over 3 or 4 days, you get to the bottom of the problem, but support is something that Orchard needs to improve on, despite Bertrand Le Roy's good will. So with Orchard you are in at the deep end.
The other downside to Orchard is that it has a very poor user interface for the END USER who isn't a programming geek. A programmer can cope with layers and zones and working with lots of them in lists. Ie, Sitefinity is MUCH more WYSIWYG and, I would say, better for the END USER.
For a programmer, however, I find Orchard, despite the minimal support, MUCH easier than Sitefinity.
Two examples of the differences between the two CMS:
Menus.
Sitefinity is great, because you have a drag and drop treeview to organise your pages, and this reflects instantly in the menu.
Orchard says they will have a built in hierarchical menu in version 1.5. However, you have to work with entering pages into a form, rather than having a graphical drag and drop situation like in Sitefinity.
Pages.
Again, in Sitefinity, you just drag and drop controls onto the page.
In Orchard, you have to configure layers and widgets in a VERY geeky (to an END USER) way.
Also, if for example, you have a site where each page is has a custom header image, plus custom content in left and right columns, then you are going to need a layer for each page that has these extra custom pieces. (Orchard "pages" only allow you one block of content). This can be a nightmare for anyone but the most geeky.
FEEDBACK from USERS:
I developed two Sitefinity 3.7 sites. One for someone with experience with WordPress, another for a couple who run a travel agency and were very IT challenged. I don't get any feedback from our users. Which is the best feed back you can get. Just look at one of the sites (the IT challenged couple):
PrestonReid
We set it up for them over 3 years ago, and haven't heard from them since. ALL the content is input by them.
If we had done the job with Orchard, we would regularly be setting up layers and widgets for them.
MY SUMMARY:
I really like Orchard. I find it easy to use as a programmer. It is a nightmare (I think) for the end user, but if you write a few modules, most of the obstacles are overcome.
For example, I have written a module called Wingspan.Views (not on the gallery at time of writing) that allows for 3 extra editors on each "page" or view as I have called them: one for a Main Image, one for Right Content and one for left content. You also have the plain old Body part to provide the main content. Menus are still a problem I am working on.
We will use Orchard for clients that we have continued involvement with, so we can set up the layers and widgets that are needed. We will develop funcitonality (modules) that will be as complex as the client needs and can afford.
For the IT challenged type of client, we will use Sitefinity 3.7. We will refuse jobs in Sitefinity if complex extra functionality needs to be developed.
NOTE:
One of the best bits of functionality in Orchard is the Shape Tracing tool. Not sure if Sitefinity has something similar.
SO WHAT IS ORCHARD AND WHERE IS IT HEADING?:
Orchard is open source and seems sponsored by Microsoft. As in I think Bertrand Le Roy is paid by Microsoft.
From reading blogs, etc, the idea is to provide code that can be used by other MS partners, eg, DotNetNuke.
To really zing, Orchard needs a MUCH more graphical user interface, otherwise End Users are going to find it way too geeky.
Which is a shame, because for a programmer, it is a great tool that is easy to work with and to configure.
The best way to describe Orchard is that the core works, but the rest of it, the interface is missing. You shouldn't have to edit XML files to configure where content is placed on a page. Ironically, the Orchard team thinks it is more important to automatically download and install modules than it is to provide decent content configuration and creation tools. It seems more like a project to demonstrate .NET's flexibility than a real product.
Sitefinity on the other hand is a more complete and functional product with years of history behind it. The new version 5.1 supports ASP.NET MVC, which unlike Orchard, doesn't add additional complexity to it. Sitefinity's backend is very easy to use. As for customization, it's architecture is very .NET centric. They leveraged as much of .NET as they could, making it fairly easy to understand.
I can't recommend Sitefinity, however, over Orchard for three reasons:
The Library Manager imposes a versioning system and likes to store information in the database. You can change it to a file provider, but this only creates a file type with a GUID as a filename. Don't expect your graphic designer to update images using FTP.
The performance is horrible and I don't mean milliseconds. It can take several seconds for the site to respond to a request even after warm up! Telerik recommends that you cache everything, but this doesn't seem to help either.
If you must have MVC, find a sample MVC application and customize it to your liking. It is likely to be more performant than Sitefinity and easier to get your head around than Orchard since your wrote it. If you don't care about MVC, I would suggest looking at the latest version of Sitefinity 3.x. Unfortunately, there aren't very many good options available in the .NET space when in comes to CMS.
I'm looking to see if anyone has any resources or tips for developing basic Drupal modules faster? Have you come up with anything to make your Module development faster?
The Drupal module documentation is kinda hard to understand and pretty massive. I'm wondering if anyone has simplified it and given techniques/tips for getting specific things done quickly. I'm currently looking for Drupal 6 and 7. Any help saving time will be greatly appreciated :-)
In general, I'd recommend picking up a copy of the Productive Programmer. There's nothing earth shattering in it, but there are lots of small tips that can increase your productivity incrementally.
For Drupal specifically, Pro Drupal Development and Pro Drupal 7 Development, though not focused strictly on speed of development, are indispensable.
Beyond that...
in the first place, if you don't have to, Don't Write Code
get familiar with the most commonly used hooks
learn to use Drush and Drush Make
learn to use Devel and Theme Developer modules
use the Schema module to generate your module's schema code, based on an existing table
use the Data module (+ this patch) to generate the code to expose your module's tables to Views
use the Form Builder module to generate form code
use Coder to learn the Drupal coding standards, which will help others help you
set up "quick searches" to allow you to quickly search api.drupal.org
learn the shortcuts in your IDE or text editor (I like Netbeans partially because of the Drupal plugin); print out a good cheatsheet
learn to use version control effectively
Well, there really no fast track to it. If you understand the Drupal API regarding module development (install, menus, blocks, forms, etc) you will grasp it. The hardest part I remember was wrapping my head around the menu system.
One thing that helped was taking simple modules and seeing how they worked, and problem solving my own solutions. Reading Pro Drupal Development helps too.
You basically need to have an understanding where to look (API function, hook, system... ) when you want to do X. There is really no need to memorize all hooks/functions in detail with all the arguments and stuff. That's something you can easily look up. Especially if you're using an IDE with I suggest (Using Netbeans myself).
Especially when you're altering stuff, try to develop some techniques to quickly figure out what code is responsible for the stuff you want to change. One example is to look at the hook_menu() definition of the module that does it and then check out the page callback and skim through the code. Things to look up: Are there hooks you can use, is it a form (if yes, what is the form_id, how is the form structured) and so on.
The best and maybe only way to get there (knowing where too look) is exercise. Every time you do something, you'll be faster the next time when you have to do something similar. I think what also helps is working on core/contrib modules together with others. You not only get to learn these modules better, you also learn how to read and understand code written by others better and you improve your own coding style.
Try to utilize proven, generic "building block" modules like Views, Flags, Panels, CCK/Field and so on. Then, the heavy lifting is done by these modules and you only need to provide the glue code to properly integrate them with your site. Might take a bit more time the first time you use these modules but you will likely save a lot time after that.
That having said, I'm not sure if the goal should be to build modules fast. I'd say the goal is to build modules better. Try to make them generic, secure, flexible, theme-able and so on with the goal to re-use these modules on the next site your building, when you need something similar.
The majority of basic drupal module development is copy and paste. If you use textmate, the Drupal bundle for it allows you to build up key bits of modules (menus, theming functions etc) just by point and click (as it contains most of the necessary code snippets; you just fill in your info).
Following the module building tutorials is good too; the truth is, if you spent 3 or 4 weeks doing it day in day out, and you already have some background in coding, you'll be just fine.
Gedit for Drupal will preconfigure the very good Gedit editor/IDE for you.
For example, a new module: create an empty module file mymodule.example. Enter that file.
module<tab> And it expands into a full, predefined module.
Or in any module: hook<tab> to see a list of available hooks. Choose e.g. menu<tab> and it expands to a full predefined hook_menu. With <tab> you can walk trough all the variable parts in that new hook, to fill in the details.
Drupal.rb Has a.o. a $ drupal generate module "modulename" command that opens an interactive shell, wich allows building scaffolds for modules. The templates from which these scaffolds are built, are overridable.
I have recently started working with Drupal on the side and have had to tackle the limitations I come up against in the Views API. More than not I find it faster and more powerful to code it myself.
It is hard to create custom views that have a specific look and feel without create custom files anyway.
Creating the pages from scratch in a *.tpl.php gives me more choice and flexibility. I have done a couple of them now and it is almost as fast.
For a developer (since this is a programming forum) what is better in your opinion:
Views or Custom templates?
I'm not even sure what you mean by custom templates (please say you're not hardcoding SQL into .tpl.php files), but no matter what you mean, the answer is to use Views wherever possible.
Reasons:
Development speed - I promise you creating a View will be faster than a custom module 99.9% of the time
Stability - it has hundreds of thousands of testers
Security - it has the eyes of many on its code
Support - there are hundreds of contrib modules that interact with Views somehow
Maintenance - Views is a Drupal standard. Using custom modules gives your site's maintenance an unnecessary learning curve.
Upgrading - Views will provide an upgrade path from D6 to D7. Your custom stuff won't.
As for your "it is hard to create custom views that have a specific look and feel" point, I think you'll change your mind after a little time with template_preprocess_whatever() functions and overriding Views templates. You have absolute control if you want it.
I am new to Drupal and I am figuring out a set of steps for developing a Web Application. I planned:
1) Develop the application without any template or graphic effect. Just create your nodes, your views, integrate some plugins and so on. Goal: to have a website up and running from a functional point of view
2) Customize plugins: if some functionality is missing, customize plugins or develop on your own
3) Choose Theme and Customize it
4) Insert graphic effects (ex. JQuery)
5) Fine tuning
I am learning Drupal so I haven't any experience. Am I figuring out correctly ?
There are different approaches. This is how I work:
Define the goal of the site
Define functions
Define menu / pages
Deleveop theme / templates. Either from scratch or themes you downlowd.
Replace dummy text with Drupal code to show content. Here you functions comes in to place.
Remebmer that a node i Druapl, is basicalle your content / your text when you write articles.
When I tried to learn Drupal, I summarized some content here : http://stiengfoto.wordpress.com/category/development/drupal/
If you never have used CMS before, find some tutorials and start with the very most basic things.
Drupal i a great piece of machinery, but it might not be the best choice as a web app framework. It depends what you want to do really, but usually web apps is a lot of custom code / logic. Here Drupal's complexity might become a hindrance for you.
If I was going to build a site or application I would probably do something like this.
Find all the modules that I need. This can involve
Finding the contrib modules that I absolutely need.
Figuring out if I should use a contrib module + alterations or build my own module.
Searching for modules that can solve a problem, looking for solutions to problems that seem common etc.
Do the actual development, and create the features needed.
This include functional jQuery like AJAX.
Theming - this can in some extend be done while developing.
First step is usually to find a good base theme for your design, like Zen.
Then you need to implement the design.
Add jQuery where needed for flashy effects
Test and bugfix.
This should be done while developing, but when all looks good, be sure to give it all some good testing to make sure that it doesn't fail anywhere.
our website resides on iis-server and is completely written with Expression Web using templates and pure html-pages based on those templates. There's also some slight functionality built using c# in code behind.
Now i've been looking into DotNetNuke 5 as an alternative, so that our content editors (no tech bg) wouldn't have such a hard time when doing updates, adding pages and so forth. Naturally we would like to keep our finely tuned css-layout and maybe add some additional functionality later, probably using DNN modules.
I'll begin with a broad question:
Are there any best practices for migrating into DotNetNuke from an existing website?
Any articles, blogs, webcasts, books etc. related to this question would be much appreciated!
https://www.datasprings.com/Resources/ArticlesInformation/MigratetoDotNetNuke/tabid/737/language/en-US/Default.aspx
http://forums.asp.net/t/843931.aspx
The last one is a bit older - not sure if these will help - I think the thing to do is sit down understand how DNN does its pages and menu etc and then map it out on paper
planning planning planning -----------------
No matter what going from html to dynamic system like DNN is going to take grunt work