I need to attach specific XML to a word document so the elements will show up in the right places. This I can do with OpenXML SDK.
The thing is I want too be able to define the Content Controls already bounded in some sort of template so other people can create the real document template the xml will be attached to. Ok not sure people will undestand what I mean so I will explain further.
There may be many different document templates that will use the same XML data and so the same Content Controls. It's up to someone else to create the document.
Scenario: Some dude that's not a programmer needs to create a new form for the usual info because of some changes ( new layout or somehting ). This has nothing to do with the XML info, that stays the same.
Optimal solution for "some dude" would be to create the document in Word and drag the Content Controls into place ( or some solution similiar). Then when the XML gets added to the document there is no problem as the Content Controls are pre-binded.
Now there are a few points here:
1) Can Content Controls be pre-binded? If there is no XML at the path won't it just stay empty without problems?
2) Will binding Content Controls to CustomXML's like this still work in future versions of Word because of the i4i lawsuit?
3) Is there perhaps another optimal solution better then this?
Thanks in advance.
EDIT:
To be more clear. I wan't to create Content Controls that would have some name to identify them and a databound xpath. However at that moment there is nothing at the path.
Another user comes in and creates a form, decides the layout on so on, and then adds the Content Controls into the places he wants the info to be.
Later on the info for item X is requested using the new form. So a copy of that form will be taken and the CustomXML will be added into the Docx file. Now because the XML shchema was known beforehand and used when deciding the paths for the CC's this XML data will be bound to the Content Controls.
One great option would be to use VSTO (Visual Studio for Office) to build a set of document templates that have your prebinding code attached. These two articles provide a good start into looking into this type of a solution:
Creating a Template By Using Content
Controls
Binding Content Controls to Custom
XML Parts
There are two threads that discuss some details of this: 1 and 2.
One of the benefits about using VSTO is that you can hook the Content Control events: Content Control Event Model in Word 2007.
If VSTO is not an option, you can always look at Add Custom XML Parts to Documents Without Starting Microsoft Office.
This should be very straightforward. Custom controls are not impacted by the i4i lawsuit and you can name them using the tag property in each control (warning - it is limited to 64 characters).
Related
I am using a Repeater web part in Kentico to pick out pages from the content tree, to generate nicely repeatable snippets of structured HTML, based on an ASCX transformation. (No surprises here - its been working great!).
However, a new requirement landed whereby alongside the existing HTML structure mentioned above, each repeated item must also have an area where we can add any amount of additional content; based on other web parts.
I have previously written a few "layout" type web parts; implementing CMSAbstractLayoutWebPart, as described here, which has allowed me to generate a repeating amount of web part zones, so I feel like I'm half way there. The issue with that though is that as it stands, I don't seem to be able to make use of the great power and flexibility of the transformations on the page type (which I really think I need to do, and seems like it should be possible..).
I thought I may be able to specify the WebPartZone control in the transformation markup directly, like in the following:
<%# Register Src="~/CMSInlineControls/WebPartZone.ascx" TagName="CMSWebPartZone" TagPrefix="cms" %>
<cms:CMSWebPartZone ZoneID="ZoneIDHere" runat="server" />
<div>
<h3><%# Eval("Heading") %></h3>
<p><%# Eval("Summary") %></p>
</div>
But the design view doesn't seem to pick up the web part zone; so I'm assuming the page lifecycle may not allow me to do this as I'd hoped.
So what I would like to know is:
Is it possible to include WebPartZone control in a transformation such that I can then bring in new web parts in Design view?
If not, what is the recommended way to go about this? (If a custom web part is the way to go, I'd like to clone the Repeater web part in the first instance, as many of its existing properties will be needed - but presumably this must still inherit from CMSAbstractLayoutWebPart?
Thanks!
Update
Good point about the editor's experience; I would definitely like to keep this as consistent as possible. The issue for me is that the requirements that drive my data structures are not always fully understood - and are certainly subject to change. Also, they are liable to vary (albeit subtly) across different products. So I've been trying to keep templates and page types more or less the same across the board, and push out the differences into page properties that drive web part config through macros. So given that the transformation approach won't work, I expect a custom web part is the right fit for me.
I shall post my findings!
I think adding a web part zone into transformation is not a right direction as web part zone should be a part of page template (not transformation) in order to utilize it.
I'd probably try to organize my content so each item you currently showing in the repeater has any number of child pages (potentially of a different type) and use something like hierarchical viewer in order to present all of them on the page. It allows using different transformation based on either page type or node level. Another advantage of this approach is that you keep editors experience consistent.
In the end, I was able to use transformation markup to specify the generation of web part zones. I went down the route of creating a custom web part that inherits from CMSAbstractLayoutWebPart, rather than using CMSRepeater web part or similar...
Here's a breakdown of things I needed to do this:
Gave the custom layout-type web part some properties with which to query the content tree, and supply them to a TreeProvider.SelectNodes() method in the web part code once it has initialised (by overriding the OnInit() method)
Gave the web part a TransformationName property so that the raw markup can be retrieved using TransformationInfoProvider.GetTransformation(this.TransformationName)
Used the markup above and resolved macros within it using each node from the node query
Example of macro resolution code (HTML transformations with macros)
protected virtual string ResolveNode(TreeNode node)
{
var resolver = this.ContextResolver.CreateChild();
resolver.AddAnonymousSourceData(node);
return resolver.ResolveMacros(rawTransformationMarkup);
}
Then I go looking for placeholder text in the transformation markup and use the methods available in the CMSAbstractLayoutWebPart parent class(es), as detailed here, to Append() the resolved markup and also call AddZone() as necessary to tap into the response string builder
Summary: The great functionality of the API allowed me to completely avoid the use of any repeater controls. I could generate web part zones as part of the layout web part usual layout generation process.
It would be nice if I could figure out how to resolve the expressions in SCRIPT tags in ASCX transformations to complete the story, but by using HTML transformations I can use the above to accomplish what I need.
We are building a Page with dynamic functionality using ASP.NET + Sitecore 7.0.
Is it practical and appropriate use Sitecore templates for:
SQL Stored Procedure Name to be invoked
JavaScript to be invoked
ColumnNames to be used etc (related to coding customization)
Or should these configuration properties remain inside the ASP.NET Project itself?
What is the primary purpose of Data Templates in Sitecore?
Are they for developer customization or customer-level customization?
The purpose of a data template in Sitecore is to define the set of fields for content items which inherit from that template. - Think of a data template as a class and the content items (pages) as instances of that class.
Templates are usually used to define the user-editable content of pages within a site, that being said you can have items to store information which is not managed by regular content editors. The question is where do you draw the line between things which should be put into Sitecore and things which should be a part of the solution. My advice is only put things in Sitecore if they need to be there. If you have to have the ability for editors or admins to configure those settings/properties.
I would say that putting SQL/ColumnNames is probably a bad idea unless you are building some sort of report builder interface in which case it may be essential?
Likewise with placing JavaScript into Sitecore; this can be OK in moderation (e.g. snippets of analytics code which content editors may want control over?). If you're placing whole libraries of JavaScript into Sitecore, you're probably doing it wrong.
One final point to note is findability/re-factorability of code: if you have code spread between Sitecore and your solution, it can make it very difficult to maintain as it is difficult to get a complete overview of code involved.
I'm not sure how to boil this question down into a sensible single-line title. I'm also new to .Net.
I want to build a web-page version of an invoice, but I want each page of the invoice to flow down the page, not be paginated. The header of each section will be the same, but the line items and the footer will be different.
I've done this before by writing html to a stringbuilder and then outputting it to a literal control, but I think there must be a better way. I'm just having a hard time conceptualizing how to do something like this with server controls because of the fact that the ID's need to be unique.
Can someone point me in the right direction here?
Thanks!
You can create custom control and give it some properties that you can modify how you want and add the same header and footer to the control. Then use it on your page how many times you would like. Check out tutorial here:
http://www.codeproject.com/Articles/87474/ASP-NET-Custom-Control
I'm trying to create a custom deployer in Tridion 2011 SP1 that can index a component to a solr instance once published. Everything is working fine but I've come across a bit of a problem with the way it indexes the components fields.
I can access the meta data fields okay by using the Component.getCustomMeta() method and parsing the XML. Accessing the normal fields however does not seem to be possible without reading in the file that is being output and parsing the output. This is not entirely feasible as the markup may change and it seems to be a long way around doing what should (hopefully) be a simple thing.
I've had a trawl through the docs and there doesn't seem to be anything available to get the field values so am I at a loss here and will need to parse the output or am I missing something somewhere?
Content fields are not exposed as such on the delivery side, content is exposed as, not surprisingly, "content".
If you really need the fields, you need to:
Produce a "parseable" output for your component presentations
Parse the component presentations as they get published.
Look at implementations like DD4T for similar approaches.
In short - you cannot do it, because Tridion does not expose it Out of the Box. The only way to do it is by changing the content output format through a template.
We have done an alternative workaround to achieve for the similar requirement. One down side with the implementation is extra rendering of Component Presentations in XML and duplicate of xml storage in broker.
Here is what we have done:
Created a Dynamic CT (XML representation of content) GetComponentAsXML and mapped to all schemas
All the Page Templates has a C# TBB that looks up the content that we need to push to SOLR
C# TBB does the RenderComponentPresentation with above Dynamic CT GetComponentAsXML, this pushes the XML (engine.RenderComponentPresentation(component.Id, componentTemplateURI)
Deployer now gets the content in xml format, in addition to the other type of component presentations (like ascx, emebedded on page etc..)
Hope this information helps.
I'm trying to use a docx read in via the OpenXML SDK as template in a .Net web app for form letters (essentially). I have a docx with the formatting I want, marked up with XML Schema tags defined from a xsd (whatever they're called, the help is exceedingly useless on this).
The only thing similar I found on Google was what seemed to be replacing the CustomXmlBlock elements with text elements with the desired data. This seems... messy and fragile.
I also have the added complication that some of the data is hierarchical, with elements for sections, and then items in that section. This would seem to completely break the above method.
So, can someone point me in the right direction for doing this, or suggest a better way to handle templating form letters?
There are a number of choices:
What you're doing, XSD Schema mapping. This was introduced in Word 2003. It was really only truly active in that version of Word as when Word 2007 came out, the preferred new method of forms became #2.
Content Controls. More on this below.
Tried and true are Bookmarks. If you're interested, there is an article here.
For Content Controls 1, the concept is simple: wrap your content controls in the hierarchy needed. That is to say, for example, have a Date Picker Content Control and a Rich Text Content Control and then group them. Then inside the Rich Text Content Control, place a Combo Box Content Control. Eric White has written a great starter article on this at retrieving content from inside of Content Controls at Processing all Content Parts in an Open XML WordprocessingML Document. This article is a much more comprehensive introduction to Content Controls in it's links Using Open XML WordprocessingML Documents as Data Sources.
More links on Content Controls:
Brian Jones' site has a lot of great articles. I believe these were his first: The Easy Way to Assemble Multiple Word Documents and Create a rich Word document based on your own custom XML (without the need for XSLT).
The Word Content Control Toolkit. Probably the best tool around for working with Content Controls.
Visual How To Content. Many articles here deal with Content Controls.
1 To work with Content Controls manually in the Word client, enable the "Developer" Ribbon from Options and then insert Content Controls and set their properties from the left-hand section of the Controls group in the Developer Ribbon.