I was trying to find layout Studio to create a custom App in sitecore 7.2, but couldnt find it. Did anyone try any customization in sitecore 7.2.
I think this is now referred to as the Developer Center.
Sitecore Start Button > Development Tools > Developer Center
I wouldn't recommend using this if you have access to other development tools that are more suited to the task To be honest I'm surprised Sitecore have kept this feature in the product.
I am not sure what you mean with Layout Studio, I have never noticed it ;)
If you want to create a custom application, you have 3 choices, all of them use Visual Studio for your coding:
use XAML/SheerUI to create your application (sheer ui reference)
use SPEAK (Speak reference) allthough Speak seems to be changing heavily in Sitecore 8.
use standard WebForms or MVC
Which one you choose, mostly depends on personal preferences and the functionality you need.
I mostly prefer using standard WebForms or MVC because of the flexibility.
Related
I'm in the middle of developing a website using Sitecore 6.5 and when my company knew that Sitecore released version 6.6 they want to use the new version instead for the project, Is there a way to convert my Items created using sitecore 6.5(webform) to sitecore 6.6(mvc) so I wont redo my work?
General content items are not affected by switching to MVC .. it would be any presentation items that you would need to update if you did make a move to MVC. As #JayS says MVC is not mandatory and you can actually mix MVC and Webforms layouts within the solution so if you wanted to convert to MVC slowly over time it would be a possibility.
Just wanted to note that there is no such thing as 'recommended releases' any more (see: http://sdn.sitecore.net/support/versioning%20policy.aspx). Lots of customers already using 6.6 in production. The upgrade from 6.5 -> 6.6 should be straightforward (but this obviously depends on the complexity of your solution).
From my understanding, you do not need to use MVC in 6.6 if you do not want to. John West has a blog about the installer and how it enables MVC. You should be able to port your existing solution up to 6.6 relatively easily, but if you wish to take advantage of MVC you'll need to alter your solution.
Note, I believe that Sitecore has not marked 6.6 as a recommended release, so you may wish to inform your company of that.
UPDATE: Thanks to Stephen for pointing out that Sitecore has discontinued using the recommended release tagging. Some of their documentation online still needs to be updated regarding this :)
I have to create something similar to Report Builder and SSRS or Open RPT but for a MFC application.
The idea is to be able to create and edit a template for reports that have to be printed afterwards. I am not confined to using MFC (I am allowed to use C#, QT, etc..), but whatever I use, it has to integrate in a MFC document application and be able to do drag and drop/resize and edit of containers (for example tables, image containers, etc).
There are some options that I considered (but they all seem overkill):
XPS, it allows for easy printing but it does not allow for editing/drag and drop.
DirectDraw, but this seems like a lot of work and I do not know if/how the printing functionality can be implemented.
QGraphicsView from QT, but I am afraid of the complications that can arise because of the integration part.
Are there any components that I can use? It does not have to be free (but that would be nice), but I should be able to integrate it in my application without installing additional software on the clients machine.
Note: I use MFC9 with Visual Studio 2010. And the target PCs have Windows 7 and Windows 8 installed.
All major components vendors have this kind of control in a way or another, my personal choice is DevExpress, but you can also look at Telerik, Syncfusion and others, just be sure that the Report Designer component can be redistributed to your end users.
I just started to look into Sitecore and I was wondering if anyone can help me enlighten what / how it is exactly from a developer perspective.
I've gone through bunch of their documentation and also their SDN - seems to me so far most of them are just drag/drop click here and there through their interface (ie. through their "Sitecore Desktop") with very minor actual programming.
Is this true? or are their actual C# / ASP.Net programming behind the scene to implement business logic and such?
I went through their basic tutorial (creating basic site for Product), and like I mentioned above, it's all mostly done through their interface without any real programming - as opposed to working with the ASP.Net MVC3 Music Store tutorial where you can see some C# programming.
Thanks!
A Sitecore developer should have the most intense and deepest understanding of Sitecore in general. Developers need to understand the CMS user's perspective (i.e. content editor's POV), they need to understand the architecture of content within the content tree, and they need to know the code, which they build. A developer should have the most intimate knowledge of a Sitecore solution because you need to know the architecture to know how to code. And to know the architecture means you know how content editors will interact with the content.
Architecture
Sitecore is a souped up database. Think of it like that. You can architecture a site how you want. But once you start to learn the principles of Sitecore architecture and best practices you'll notice a pattern. Everything in the content tree is an item. The model for each item (called a template in Sitecore terms) is defined by an architect (which is often often a developer). In fact, even if there's a separate person for the architect role, they likely have developer knowledge as architecture defines the way things are developed. In fact, the architecture is one of the most important things.
Code
Code is broken down into various types, but in its simplest form there are two main things: layouts and sublayouts.
Think of a layout as what a normal a ASP.NET application uses a MasterPage for. In Sitecore, a layout is actually a ASPX WebForm, but it acts as a master page. Some examples of layouts you could have on your site are: One Column Layout, Two Column Layout, Print Layout. These would respectively translate to a header and footer with one main content area, a header and footer with a main column and side bar, and a print-optimized layout with maybe a logo and just main content.
Sublayouts are all of the little components that make up a page. Examples include: main navigation, a promo box in your side bar, a list of 5 recent news pieces, a CTA for a promotion, a sidebar slide show, etc. These components could be modular and moved around by content editors, or they can be fixed within the location of layouts, e.g. a promo box could always appear in the sidebar of the Two Column layout as a business rule defined in the code.
To answer your question about is there actual coding, yes. You write code using ASP.NET controls for Sitecore and Sitecore's C# API to access data that is populated into the templates on each item. So, if you had an item for a page that had a page title for the title tag, your code would use the Sitecore API to access the field "Title Tag" from the template (remember a template in Sitecore speak is a data model) in Sitecore.
Coding For Sitecore
I'd say there are two approaches to coding. I believe you identified one of them, which is using the internal tools within Sitecore's interface. Sitecore has a section called Developer Center that lets you create layouts and sublayouts. Frankly, compare this to using Visual Studio in Design Mode all of the time. I have never once used the Developer Center to do my coding. Instead, I code in Visual Studio which is the most common technique for people to code for Sitecore (at least I think it is). Now if you're wondering, how does the coding connect to Sitecore's data... well the answer is within Sitecore. There's a section of the tree called Layouts. In here are the names of your layouts and sublayouts. Each layout and sublayout item has a path that maps to either a ASPX WebForm or ASCX User Control, respectively. This is how the code on the file system that you write in Visual Studio actually gets used by Sitecore. These layout and sublayout items are then used via the Presentation > Details tabs for each item in Sitecore.
Beginners
One of the hardest things with Sitecore is the learning curve. I've been using Sitecore for years now and love it. In fact, its all I really do. It's by far my favorite CMS as its completely customizable and very developer-friendly. Sitecore recommends that new developers take the developer training classes so they can basically explain what I explained above in an actual training curriculum. In this training you will learn the architecture, and then how the code connects to it. Training involves hand-on architecture work within the content tree and hands-on coding. The recommend training courses for new developers are:
Getting Started With Sitecore Development: Sitecore XP 8 Website Development for .NET Developers (4 days, certification)
Further Training for Sitecore Certified Developers - Sitecore XP 8 Livefire MVC Workshop (1 day, no certification)
Sitecore is an ASP.NET application. That means that you can write any code you like. Our team creates all of the Sublayouts (ASCX files) and Layouts (ASPX files) ourselves in Visual Studio, not the editors built in to Sitecore.
Some installations of Sitecore that I have seen barely rely on the CMS to do the rendering. Instead values are pulled via the codebehind as if Sitecore was just a database. That can work fine in some situations.
The most impressive Sitecore instances use all of the available tools that the developer has access to. Using the Sitecore tools the way they were designed to be used allows some pretty impressive editing options for the (often non-technical) content editors.
For example: Using a Sitecore Fieldrenderer instead of just a placeholder or label will not only automatically render content appropriately (whether they are images or rich text), but it will allow the content editor to edit the content right on the web page as opposed to the only on back end that all CMS systems have.
Workflow is another killer feature for a customer that is the right size to afford Sitecore. It lets you build an approval process for items in the tree. That way legal, marketing and the graphics team call all sign off on a new page before it goes live. Then when all of the approvals are finalized, the site publishes automatically.
To sum up: Sitecore is a .NET application, you can code whatever you want. That means you should focus on the CMS features and make sure it is a good fit for you from a content editor perspective and a financial perspective.
Sitecore is in most cases just drag & drop as you've described in terms of content authoring but to actually turn this content into a webpage you need to implement layouts, sublayouts and so on.
Layouts are generic ASP.NET pages (aspx), sublayouts are just web controls (ascx) and if you prefer you can also use XSLT to generate HTML but it's useful only for basics (Sitecore only supports XSLT 1 at this moment). These ASP.NET controls are more less the same as standard web forms controls with code behind and so on. The difference is that Sitecore is your datasource and it gives you an APIs to access all relevant applications.
But Sitecore APIs also goes beyond that and allows you programatic access to virtually any component of the framework. The APIs are well docummented and quite easy to understand and they can be used for more complex scenarios.
Latest version of Sitecore (6.4) allows you to also use MVC framework for layouts/sublayouts creation if you don't like web forms that much.
Layouts and sublayouts are a great way todo any customizations from a coding standpoint but there is a third way that is not mentioned here. We call it sitecore extensions. I often find that to meet customer requirements, creating custom assembly's for workflow actions or template commands is the only way.
For example, a standard email notification upon entry into a workflow state only allows for you to apply server, recipient, description etc.. to action item field. In our case these values constantly change so we need to be more dynamic. A custom assembly applied to the action allows us the flexibility to do a number of things that the standard action will not. Another example was that we needed to have a treelist in an item scroll to and highlight the current item. The way todo this was to override the core treelist action with our custom assembly.
Keep in mind that adding alot of code to the layout (which could be a master page for a ton of pages) ramps up the runtime overhead.
From a UX perspective, Sitecore is impractical, overpowered and too complex to be effectively implemented for teams with typical content contributors and editors. No thought has been put into streamlining content creation or simple page template maintenance. I would never recommend Sitecore to a team without:
HTML authoring/editing skills
FTP concepts & Site tree understanding
Data management skills
The system is built for developers, with users as a very distant after-thought. In my experience, it offers a huge number of benefits — being a usable system for every-day content authors is not one of those benefits. The system is so modular and over-managed, it forces users on every level to make decisions that only complicate otherwise simple operations. Content publishing is extremely modular, and a big benefit for developers; it is a catastrophe for everyday users.
If you're a developer, Sitecore is a wonderful building environment. It's powerful and flexible.
If you're a user, Sitecore is task-heavy and offers the steepest learning curve I've ever encountered with a CMS. UAT has been a nightmare.
Is it possible to transform a rails application to a desktop application? And if yes what is the best way of doing it.
And where should I start if I just want to create an simple windows desktop application that shows a few columns from a Mysql Database and check if they have changed.
Transform in the literal sense, no, no such tech exists. However, you can make a rails app that's live on the web, or any other web application appear somewhat like a desktop application (with its own icon, and even some OS integration) by using a "Site Specific Browser"
OSX: http://fluidapp.com/
Windows (and OSX): https://mozillalabs.com/prism
I think it could be possible to use activerecord but you would need to do something different when dealing with the presentation layer. Maybe run your application using JRuby (see the gem redcar for a good example of how to implement a desktop application in Ruby/Java)
There are a few things to consider:
Do I just want this to run using a specific window manager?
Is it important for this to be cross platform?
My guess is that you would want to JRuby in conjunction with SWT and then reuse your data layer (models etc).
I think it could be done but you will have to pick and choose from some of Rails' sub-gems.
Rails, no, but Ruby can be used for this. I would take a look at JRuby for that. Write you app in Ruby but run it on java and access all the libraries it has. FXRuby is also an option.
Rhodes is supposed to be MVC and close to Rails but I don't know how close. Its intended for mobile apps though.
This won't be direct. Desktop apps coud be done using shoes which is a really great tool.
Here is a basic example:
Shoes.app :width => 300, :height => 200 do
button("Click me!") { alert("Good job.") }
end
They provide many apps examples here: http://the-shoebox.org/
And for basic examples: https://github.com/ashbb/shoes_tutorial_walkthrough
For more details see: http://shoesrb.com/
I have recently completed a detailed investigation regarding GP functional test automation possibilities with QTP, TestComplete, and other GUI recognition/interaction tools.
In short, none of the tools acted well. Mentioned above did best but still featured a lot of hard-coding in recorded sample scripts. QTP did significantly better though.
Some of the GUI were recognized under .NET (swf... in QTP) and handled well. Some other were recognized as swfObject only but accessing native methods and properties allowed performing required interaction.
Finally, object internally named "Microsoft.Dexterity.Shell.DexDialogHost" renders objects that seem don't have Windows Handle and thus unrecognizable by QTP. I haven't found any detailed documentation on those objects family (like class reference to find out names of methods).
So I was wondering if someone could share experience automating GP and what tools / approach were used.
Thanks.
If QTP doesn't recognise some controls you can extend the set of controls it supports by using .NET Extensibility. This allows you to add new functionality which is relevant for these controls but is not supported out of the box by QTP. Note that some .NET programming is required.
The documentation for .NET Extensibility is available at Start > Programs > QuickTest Professional > Extensibility > Documentation > .NET Add-in Windows Forms Extensibility Help
Fact of the day: The SWF in .NET objects' names in QTP stands for System Windows Forms.
With regards to the objects that were partially successful, the ones you noted were recognized as SwfObject - if these logically map to a standard class, you can configure QTP to treat it as a standard class. For example, if you have an SwfObject that behaves like a button, you can configure QTP to record and replay as if it is a standard button.
[removed suggested keystroke+clipbaord work-around as it is inappropriate for this situation given further information that there are multiple Dexterity dialogs, each with many objects]
It took a while for me to conduct a research, and then practically prove the concept.
I started series of posts about Great Plains automation success story where I put all the details and steps of my investigation along with sample code.
http://automation-beyond.com/2009/08/24/great-plains-automation/
http://automation-beyond.com/2009/08/26/dynamics-great-plains-gui/
http://automation-beyond.com/2009/09/01/gp-automation-utilizing-com/
(to be continued)
Here's the summary.
Microsoft Dynamics Great Plains has its own completely independent GUI/Event system (Dexterity) that makes it cross-platform product. The same thing makes it almost completely "black box" not accessible from outside.
Platform-specific engine supports COM Automation and various integration models for Windows platform. All these are gathered under Continuum Integration Library name.
What is especially useful for Test Automation needs, Continuum provides high-level methods to simulate user inputs for the GUI thus acting the same way as Test Automation Tool does.
Wherever Continuum doesn't cover Test Automation needs, direct calls of sanScript (Dexterity's internal scripting language) could be executed in real-time.
With all the above, I created custom "Dexterity GUI" component for Quick Test Professional enabling functional test automation of Microsoft Dynamics Great Plains application. Of course, without any use of keyboard/mouse hard-coded workarounds.
Thank you.
You can download the .NET Add-In from hp.
link text