VisualForce pages can have the format:
<apex:page standardController="Case" >
<div id="content"></div>
<script>
... javascript to render a UI into #content ...
</script>
</apex>
which means it can appear on the "Case" layout. If you want a generic VisaulForce page (appearing all alone on a tab, let's say) you can remove the standardController parameter:
<apex:page>
...
</apex>
Is there a way to specify that a single VisualForce page can appear anywhere? (In our case, it's a javascript utility which is not layout-dependent).
I'm new to SalesForce, and the closest I could come up with would be to dynamically populate the standardController field (if that is supported) but I feel there must be a better way. Any help is greatly appreciated!
Do you mean it's a piece of javascript you can include in other pages? If so you should be doing it as a component, or you could put the JS in a static resource and include that in your pages.
If it's actually a page, you can include it in a page layout as well, though it's a little clunky and goes in an iFrame so that would probably cause problems for you.
Related
I am new to Liferay, and I still don't know the difference between the various 'kind' of Liferays.
This Liferay is what I am talking about.
I understand that you have to create a page first, and then add components (fragments) in it.
I also understand that you can go to fragments, and create a custom fragment with a custom CSS, and then import it into your page.
However, what I want to do is have a global CSS that I can use for all fragments inside a page, rather than having to add CSS for each fragment.
Is that possible, and if so, how?
I know I can use the 'style-books' which apply to an entire page, however, I don't know how to customize them, and it doesn't seem that that's even possible.
To avoid coding, you can use the css additional textbox provide by theme settings.
It's a whole page css addon for every pages in the site
I am using AEM 6.2 and trying to create a parsys component in crx, using the code below
However, the height of this parsys, in edit mode, comes as 0px.
Attached are the screenshots.
When I manually change the height to some values eg. 40px, it looks fine.
Note: I am not using any client library for the above page. (no css and js)
Futher, All sample sites like geomatrix etc have parsys showing correctly.
Could anyone guide me with what I am doing wrong?
I think that the problem is outside the component or any of the code shown here.
I think what's happening is that the css style for the div that gives the droptarget placeholder its dimensions is not loading.
That's loaded as part of the AEM authoring client libraries which you should be inheriting from the foundation page component.
Examine your page component's sling:resourceSuperType property. It should point to either wcm/foundation/components/page or wcm/foundation/components/page or inherit from a component that does.
If that is set then you have may have blocked one of the scripts within it, quite possibly head.html.
Include following code in the head section of the page component's rendering script.
<!--/* Include Adobe Dynamic Tag Management libraries for the header
<sly data-sly-include="/libs/cq/cloudserviceconfigs/components/servicelibs/servicelibs.jsp" data-sly-unwrap/>
*/-->
<!--/* Initializes the Experience Manager authoring UI */-->
<sly data-sly-include="/libs/wcm/core/components/init/init.jsp" data-sly-unwrap/>
For resolving your issue, you need to include init.jsp in the first before writing down the parsys code. I mean write like this.
<head>
<sly data-sly-include='/libs/wcm/core/components/init/init.jsp' />
</head>
<body>
<sly data-sly-resource="${'par' #resourceType='foundation/components/parsys'}" />
</body>
I think #l-klement pointed it out correctly that the problem is outside component. When I rename the landingpage.html file to body.html it starts working fine. I think this may be because of different files like head.html etc present at wcm/foundation/components/page which is required to provide proper styling and load certain required client libraries which assigns proper styling to parsys.
If the above is true, my next question would be, How can I have my own head.html, body.html, header.html, footer.html etc files without compromising with the parsys styling?
I understand that the background page of a Chrome extension is never displayed. It makes sense to me that a background page should contain only scripts. In what situations would HTML markup ever be needed?
At https://developer.chrome.com/extensions/background_pages there is an example with an HTML background page, but I haven't been able to get it to work (perhaps because I am not sure what it should be doing).
Are there any examples of simple Chrome extensions which demonstrate how HTML markup can be useful in a background page?
Historical reasons
The background page is, technically, a whole separate document - except it's not rendered in an actual tab.
For simplicity's sake, perhaps, extensions started with requiring a full HTML page for the background page through the background_page manifest property. That was the only form.
But, as evidenced by your question, most of the time it's not clear what the page can actually be used for except for holding scripts. That made the entire thing being just a piece of boilerplate.
That's why when Chrome introduced "manifest_version": 2 in 2012 as a big facelift to extensions, they added an alternative format, background.scripts array. This will offload the boilerplate to Chrome, which will then create a background page document for you, succinctly called _generated_background_page.html.
Today, this is a preferred method, though background.page is still available.
Practical reasons
With all the above said, you still sometimes want to have actual elements in your background page's document.
<script> for dynamically adding scripts to the background page (as long as they conform to extension CSP).
Among other things, since you can't include external scripts through background.scripts array, you need to create a <script> element for those you whitelist for the purpose.
<canvas> for preparing image data for use elsewhere, for example in Browser Action icons.
<audio> for producing sounds.
<textarea> for (old-school) working with clipboard (don't actually do this).
<iframe> for embedding an external page into the background page, which can sometimes help extracting dynamic data.
..possibly more.
It's debatable which boilerplate is "better": creating the elements in advance as a document, or using document.createElement and its friends as needed.
In any case, a background page is always a page, whether provided by you or autogenerated by Chrome. You can use all the DOM functions you want.
My two cents:
Take Google Mail Checker as an example, it declares a canvas in background.html
<canvas id="canvas" width="19" height="19">
Then it could manipulate the canvas in background.js and call chrome.browserAction.setIcon({imageData: canvasContext.getImageData(...)}) to change the browser action icon.
I know we could dynamically create canvas via background.js, however when doing something involving DOM element, using html directly seems easier.
I am trying to customize the Liferay UI by using custom theme using base as as "_Styled" theme.
I have my own css files which I coped to _diff/css folder of theme and imported them "custom.css" file .However its breaking the presentation of liferay.In my custom CSS I have styles defined for all the standard tags like body,div etc which is impacting the liferay UI too.
How can I resolve this conflict? Thanks in advance!
Quick (and not the best) solution is to remove contents of liferays css file (for example "base.css") and save this empty file in /diff/css/ folder of your theme. This way the base.css will get overriden with your new empty file and thus no styles will get loaded. And your custom.css will be the only stylesheet that is taken into account.
Well, of course it all has an effect on the rest of Liferay as well. Liferay provides quite a bit of the HTML DOM of your page, and if you change the presentation of all of those elements, you'll have to take care to style Liferay's elements too.
Is this a conflict? No. Let's go for the simplest case: You declare div {color:green;}. Of course, now everything, your components as well as Liferay's components, use green text. If you only want to style your own portlets, you might want to specify some portlets: div.portlet-my-own-application {color:green;}
I know that color is a too simple usecase, but I hope it illustrates the solution strategy.
Rather than following Artem Khojoyan's suggestion to override Liferay's base.css, I'd recommend to take a look at the resulting css, what's effective etc., and simplify your own css - adapt it to be used within Liferay - by inspecting the effective CSS for every elements that looks off. Firebug or any of it's relatives are your friend.
I'm afraid, with the details "I'm doing something which has an effect on Liferay UI" there's nothing much more to help you. In fact, I'd hope that what you do has an effect on Liferay's UI... You'll just need to find the proper CSS code
Ideally if your styles are loaded from custom.css, then will overwrite liferay default styles.
In some cases, to overwrite a style in css, you can use !important
for example, liferay default style
body {
background-color: #fff
}
You can specify your style to consider irrespective of order of loading
body {
background-color: red !important;
}
I've been searching high and low for a satisfactory answer to this and failed. I hope StackOverflow can deliver for me!
I am using SharePoint Foundation 2010 (my first real attempt to deep dive into SharePoint), with (among other things) a custom web part; the master page for the site uses a CSS file supplied by the client and to which I must adhere. The issue I am having is that SharePoint, by adding several SharePoint specific CSS classes to the web part HTML structure, is conflicting with the client's styling. After some digging, I've found that the ms-WPBody class and its various element selectors are the chief culprits.
I could add !important to everything in the client style sheet, but that is verboten. I could insert some very messy styling into the child content of the web part in an attempt to override the SharePoint styling, which is the course I've been pursuing of late, but it's been getting messy. Or, I could try to remove the class from the web part, which brings me to my question:
How can I remove or otherwise override the CSS class names inserted into the HTML structuring for a SharePoint web part? I don't know enough of the inner workings of SharePoint to know what to hook to make this change, and my google-fu is fail on the subject. CssClass on the ASP.NET web control markup is obviously ignored, probably some holdover inherited from WebControl.
Help me StackOverflow! You're my only hope!
Edit
I apologize for not making it clear before, but I would like to state that I grok CSS and am not looking for help with styling. What I really am looking for is how to remove the CSS class emitted by SharePoint. Can anyone help there? I'm going to remove the CSS tag, since that appears to be confusing people. This question isn't really about CSS, it's about SharePoint.
CSS has to match the html that it is applied to - with generated html like that produced by SharePoint (or standard asp.net webforms for that matter) it is usually far easier to modify the css. If adding important is not an option you can usually do something using more specific selectors - ie a style defined as "table td" will override one for "td" though they actually select all the same elements. You can use this approach to undo any bits of sharepoint styling that are causign issues.
If you really want to change the classes sharepoint puts on the page, use jquery - trying to do that server side is really not something you want to get into on your first sharepoint project.
I'm not sure I follow, but why not wrap your webpart in a container div and then style to your heart's content:
<style type="text/css">
.ms-WPBody {
background-color:red;
}
#myCustomCss p
{
background-color:Blue;
}
</style>
<div class=ms-WPBody>
<div id=MyCustomCSS>
<p>Hello world</p>
</div>
</div>
In 2007, we had to worry about making sure your stylesheet was named last alphabetically so that it was applied correctly. Prefix your css file with z to see if it helps.
Here's a reference article about the issue:
http://singchan.com/2009/12/29/branding-sharepoint-2010-collaboration-sites-part-2-in-a-series/
Here's some typical Web Part HTML:
<div style=""
allowexport="false"
allowdelete="false"
class="ms-WPBody ms-wpContentDivSpace"
width="100%"
id="WebPartctl00_m_g_d0420a1c_44b7_4009_81c9_2bbcf9b325e9"
haspers="false"
webpartid="d0420a1c-44b7-4009-81c9-2bbcf9b325e9">
<div id="ctl00_m_g_d0420a1c_44b7_4009_81c9_2bbcf9b325e9">
Web Part Content goes here...
</div>
</div>
The trick is that the Web Part itself is the inner DIV (and all its children). The outer DIV (the one with the ms-WPBody class) is the WebPartZone. This control is sealed, but you can write an Adapter that will render the WebPartZone however you want. Most of the examples are for table-less rendering, you could write one that maintains the existing structure, but removes the classes.
To me, coding all of that and then registering it in the compat.browser of App_Browsers for the Web Application seems like overkill, so I'd probably go with jQuery (but if you do the Adapter, I'd love see it).
Or just add a Content Editor Web Part and override the CSS style element in the HTML:
<style type="text/css">
.ms-stylebox {
border:o important;
}
</style>
-- Peace!
how are you loading your CSS file? IF you are loading it in part of the head of your master page, or through just setting a custom.css, you can try loading it outside of the head. This should cause it to load after core.css and therefore allow you to override the standard classes as needed.