I have an existing site in a path, and I've pointed the DreamWeaver site to it.
Under \templates there is a master.dwt file. But whenever I save this file, none of the html files which should make use of it change. What do I need to do to get DW to update the html files that make use of it? And how does DW know which files should be updated based on the template changing? Does it use an internal store or something because every time I copy the site to another machine, I'll need to link up all the pages to the relevant templates again.
I've tried going into Modify | Templates | Apply, but no templates are listed. I have a .dwt file in the path so why isn't it picking it up??
There's several possible issues in play here:
For Dreamweaver to properly recognize the existence of the template, the folder in the root of the site should be Templates and not templates.
Once Dreamweaver "sees" the Template properly you then need to make sure that the proper code is present in the child HTML files so Dreamweaver knows which files to update via the template. This code takes the form of HTML comments scattered throughout the page. You will always have the following line after the <html> tag:
<!-- InstanceBegin template="/Templates/TemplateName.dwt" codeOutsideHTMLIsLocked="false" -->
After that, editable regions are delineated with code that will look like this:
<!-- InstanceBeginEditable name="someregion" -->
stuff you can edit
<!-- InstanceEndEditable -->
Without the above, the child pages will not respond to the template.
Now for the real bad news. Unless the existing pages match up with the template exactly, you are going to have all kinds of problems getting the template to play nicely with the existing content. Doing Modify | Template | Apply Template to the page when the page is already fully formed will generate a dialog box that asks you map the content to the editable regions in the template. But if the rest of the design elements vary from what the template contains, Dreamweaver will preserve those tags alongside what the template will introduce which usually creates a ton of duplicated tags and broken layouts.
You would be FAR better off creating new, blank pages from the Dreamweaver Template and copy/pasting the contents into the editable area and then overwriting the "old" pages with the Save As command.
I just encountered this issue myself. I realize this original question was posted some time ago, but for anyone who might encounter this problem in the future, I am posting my solution.
If the only changes made to the template relate to one or more elements contained in an attached/linked file (such as a CSS style sheet or JS file), which changes Dreamweaver allows directly from the .dwt template itself, using the style boxes at the side/bottom, then Dreamweaver does not perceive any change to the actual .dwt file itself. If you want those changes to "take effect" and apply them to all pages, you might type a change to the .dwt file itself, click "save all" - undo the change and click "save all" again. This step is really not entirely necessary, as the changes to dependent files can be affected to the website by putting the dependent file to the website.
Also, Dreamweaver will apply changes to CSS/JS dependent files, across the board, but may continue to use a cache, until closed and reopened.
Related
I'm building a blog-like template using Sculpin, and need to populate a sidebar with categories. This sidebar is supposed to be visible on every page. However, Layouts don't seem to interpret YAML frontmatters like Sources do. This makes it problematic to create a globally visible menu that gets populated based on the content data (eg. posts).
I can reference data.posts_categories if the current Source's YAML frontmatter has:
---
use:
- posts_categories
---
and I'm fine with just putting it in every Source file. However, there are also Views (like "post.html"), which again do not support YAML information.
Based on this post, apparently you can declare a list of properties. However this apparently only allows to declare constants.
In other words: I need to be able to reference posts and categories in layouts (in the master template). Is there a way to do that, or something similar?
I'm using Liferay Portal 6, The .sprite file is not specified in the source code, however, it's included in the URL with a slash dot, then it's blocked by a security program.
When I delete those file in theme/docroot/images and I deploy the project, they are generated again.
I would like to know how to manage those files or rename them?
You can open those files: It's combined images - look up "CSS Sprite" for a thorough documentation. They're used to limit the number of requests that go back to the server. Without sprites, you'd have every theme image loaded individually. With them you only need the sprite once, resulting in a significant performance boost: You want to have as few http-requests per page as possible, and sprites are one automatically handled way to help you achieving this.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
Are you able to do the same thing for Xpages and custom controls design elements?
====================================================================
My question should have been clearer. What I want to accomplish is to copy an existing cc and give it a new name, programatically. The app will then close and reopen (or refresh or get rebuilt) so that the app can "see" the new cc. If I copy the cc it will only have one field on it. I will add custom code later. I could just create a new cc with no code in it, that would work too.
I am not familiar with the DXL exporter but I can research it. Using that can I just export the design of the cc to an XML file in a temp directory, use the transform to change the name, and then import the control?
I think the XPage or Custom Control design elements are probably under MISC_CODE or MISC_FORMAT design elements in a NoteCollection.
However, accessing that design element is the easy part. Doing a create / rename / change etc is a much bigger task.
Remember that the XPage or Custom Control XML file is only a starting point:
XPages and Custom Controls also have a .xsp.metadata file, as you'll see with source control.
Custom Controls will also have (and need) a .xsp-config file.
There are corresponding .java files for every XPage and Custom Control in the Local source folder. They're created by a builder based on parsing the XML. I don't think you'll be able to create those programmatically. I'm not sure of the impact of renaming them.
For Custom Controls, even if you can rename the .java file, it's referenced in the .java files of relevant XPages. Updating those is goiong to be a significant task.
The XPages runtime doesn't even use those .java files. Instead it uses the .class files in WebContent\WEB-INF (you need to use Project Explorer view and modify the filter to see those files). This is compiled byte code, so you won't be able to update the .class files for XPages containing renamed Custom Controls, as far as I know.
Even if you can rename the .class files, the XPages runtime almost certainly won't use them until either a Clean (which will overwrite anything you've done) or an HTTP restart. As far as I can tell they're cached.
Depending on your use cases, it's possible not all these points will be an issue, e.g. if you're modifying the XML files and building with headless designer.
I suspect this is why nothing was added to the NoteCollection object or a specific NotesXPage / NotesCustomControl API class added.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
This is only partially true. There is a LS API to create/alter views and outlines. Good luck with other design elements - although they're standard "notes", so you can access their items, in most cases you won't compile them and there will be some problems with signatures (real experience with TeamStudio CIAO).
Your question has two points of view - do you want to alter design elements in design process or alter running application?
To help a designer you can go the way of Eclipse extensions and enrich tools in IBM Designer to help developer. Something like TeamStudio Designer. In this case you need to look for source design elements, mentioned by Paul.
To enrich application you don't need to alter source design elements. IBM Designer transforms XML in source code to a Java code (JSF framework) - so you can generate your Java code from anything you wish. Take a look inside Local\xsp folder of NSF in Package explorer. You will find Java sources made from your XPages and Custom Controls. So if you don't need to work with design elements, go for Java components - they can be built on the fly.
And of course, there is always the option of DXL framework - so you can clone/alter design of the application through XML transformations. Good starting point: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/ls-design-programming.htm
I moved a set of templates to a new folder also named Templates so the instructional designer can see them in her "New page from Template" window. For some reason, I as the programmer can see the list if I try to make a new page from template, but the ID couldn't. While moving them allowed her to see them, it broke all the relative links to the js script src files. And when she tries to save the template page, it tells her to try and copy files and the absolute links don't get reset to their relative paths.
Is there a way to reset the relative links to those .dwt files? When I open the .dwt files, the relative links look correct; but when the ID makes a new page and then chooses a template to use, the links break at that point.
What do I need to do make the templates retain the relative links again?
Thanks in advance!
Carlos
When I moved the templates, it wasn't just in a new folder, but on a new level in the folder structure, so the old script src address "../../scripts/nav.js" wouldn't work because in its new location, it overshot the folder by one level and hence couldn't find the js file in question. Readjusting the relative links to compensate for its new location and structure level fixed this issue.
Carlos
Here's my situation:
I'm working in SharePoint 2007 Enterprise, I have a feature that creates a list for me when I deploy and activate it. My usual workflow thus far has been to deploy the solution, activate it, then open up SharePoint Designer to customize the list.
My customizations are typically pretty complex, but I'll keep things simple. In this case, let's just say that I edit AllItems.aspx, convert the data view to an XSLT data view, then I add one column with static text.
I've used a few different tools (SPSource, VSeWSS, SharePoint Manager, OCDExportList, etc) to extract my custom schema.xml and all the default views, but I have yet to have any luck figuring out where the the code for AllItems.aspx is now that it's been customized.
When I extract (using any of the tools above) AllItems.aspx is no different than the default. The <View> element in schema.xml is reduced to one line, for example:
<View DefaultView="TRUE"
MobileView="TRUE"
MobileDefaultView="TRUE"
Type="HTML"
FPModified="TRUE"
DisplayName="All Documents"
Url="Forms/AllItems.aspx"
Level="1"
ContentTypeID="0x" />
I'm really stuck here... I've got no clue what to do. Is it even possible? It would save me a great amount of time (and documentation) if I could include my customizations in my feature.
If there's any other info I'm missing that would help, let me know... thanks!
Latest findings:
I've found out a bit more in the past couple hours. If I save the list as a List Template, then save the .stp file locally as a .cab file I can extract its contents. One of the files is manifest.xml which contains the schema.xml as well as a few other sections.
One of those sections is a <webparts> section that has a <webpart> for each view. Each of those <webpart> elements contains a really long string of characters... no clue what those characters actually represent.
The important thing is that I think any custom views have to actually be Web Parts if deployed as part of a solution... but I'm not positive.
I have faced a similar issue a while ago. I had to create a very customized view and I had to give up the ListFormWebPart completely, and have created my own webpart to render the data.
Generally, when you customize the aspx file in SPDesigner, all your changes will be in the aspx file itself. Open it in SPDesigner and you will see there all the changes you have made. After you have converted to the XSL Data View, the standard ListFormWebPart is replaced by a DataFormWebPart, which doesn't care about the <View> tags specified in the schema.xml; Look in the aspx file itself for the ListFormWebPart.
Why not do all the customizations you want on a list, save the list as a template (it will include the associated AllItems.aspx) and then use that template in your feature to create your list? You could add the extracolumn from code (if it's dynamic and cannot be included in the template), and so on.
Yes you can. Get the Sharepoint manager tool from Codeplex
http://spm.codeplex.com/
Install it on a machine in your farm, it will allow you to browse the farm via a tree view that shows all objects.
Make the list via the Sharepoint GUI, then browse to it w/ SPM.
SPM will allow you to extract the MOSS/WSS created xml that describes the list view (it shows up in the left hand property grid), which you can then plop into your manifest.xml
I have a similar issue and have been doing a lot of research into this. The dataview web part to me is one of the most powerful components in Sharepoint. Unfortunately I have to provide my solution as a .wsp package and that means that I can not just make the site and use Designer on that site. I have taken a 2 step approach in that I used designer to create my dataview and I also edited the code of that dataview to replace the ListID and Guids to ListName and the actual list name. This allows it to be exported and used in any page/site as long as the list name is the same. I am creating a webpart page document library also in my solution and I believe I can add the pages that have the webparts to this library using the onet.xml file. I will try to get the results of that test in as soon as I can do it.