I'm having problems with sifr showing the replaced text and the flash rendered text. All the css files are loading correctly, however I'm implementing this in sharepoint 2007 so it's possible something else is causing the problem. This is the browser output I'm getting:-
h1 class="large sIFR-replaced" style="">
object id="sIFR_replacement_0" class="sIFR-flash" height="61" width="1238" type="application/x-shockwave-flash" name="sIFR_replacement_0" data="/Style Library/sifr/cartonnage-alternate.swf" style="">
/object>
span id="sIFR_replacement_0_alternate" class="sIFR-alternate">hello hub
/h1>
(I've removed the < down the left hand side of the above code so it displays on stack overflow)
The is not hiding and for the life of me I can't see why - if it's somthing obvious I apologise!
The CSS to hide the .sIFR-alternate text doesn't seem to be applied. Inspect the page with Firebug and see if that's the case or if the CSS is conflicting with something else.
Related
We're having a weird problem in our AEM 6.3 application.
For some reason, the link to the contact-us page gets rendered with a space at its end, making it useless.
I'm trying to figure this out but I'm kinda new to sightly (I used to be working on CQ5).
To visualize it better, the configured link in the page properties is:
/content/app-name/hk/hk/info/contact-us
And the code in the HTML/sightly page is:
<a href="${inheritedPageProperties.linkToContactUsPage # extension='html'} ">
Contact Us
</a>
While what gets rendered in the actual page is:
<a href="/hk/hk/info/contact-us%20.html">
Contact Us
</a>
This happens only in the chinese pages of the site, I'm not sure if this is relevant or just a coincidence.
At first I thought the problem could be the blank space at the end of the href attribute, but shouldn't it result in "/hk/hk/info/contact-us.html%20" then? Also why would this problem affect only the chinese language pages and not all the other languages?
AFAICT you do have a space in the page properties link:
Please remove the space in your
<a href="${inheritedPageProperties.linkToContactUsPage # extension='html'} ">
like this
<a href="${inheritedPageProperties.linkToContactUsPage # extension='html'}">
grails v 3.3.9, fields plugin
fighting with fields plgin and theres a problem when rendering domain objects and using bootstrap
i've got a sample here from a simple standalone page to show the problem
<p>f:display category </p>
<f:display bean="maintenanceAgreement" >
</f:display>
<hr />
<p>f:field category</p>
<f:field bean="${this.pageScope.maintenanceAgreement}" property="category">
<g:render template="/_fields/map/displayWidget" ></g:render>
</f:field>
<hr />
in essenence i have added a template in "/_fields/map/displayWidget" that renders a drop right table on a button
when you render a map field directly from your Domain object the sample table opens and you get all of the table
however when you
you can see the differences between using f.display (has clipping problem), f.field ( which seems to work) and f.all that ignores my _fields/map/_displayWidget.gsp
I dont want to have not use the fields plugin but its not working with bootstrap templating
has any one come up with a fix for this problem?
the project demo page is here
github standalone page to show rendering problem
the attached shows the output as you try each and select category property
well goldarn it another 2 days down the pan - but i have it !
I thought at first it was something to do with fields plugin processing. so i hacked a clone of plugin project locally and added some bits so i could watch it/debug step through it
in doing so i noted that my dummy web domain class page i'd cut across to the plugin didnt have the clipping problem. but the styles were not the same so i copied main.css and grails.css from ordinary project back into the plugin, then re rendered in the browser - and the clipping happened again.
so its in the css!. some very careful watching of browser and looking at the browser 'inspect' indicated that the clipping seemed to be enabled very early on in the journey.
so in my dummy page i just used
I then spent a day wandering round the various bits of fields plugin as its not that well explained anywhere.
if you look at the plugins taglib display method, by default that triggers the /templates/fields/_list.gsp. naming is a little odd but its the gsp that renders the domains persistent attributes as an ordered list - the plugins default _list.gsp looks like this
<ol class="property-list ${domainClass.decapitalizedName}">
<g:each in="${domainProperties}" var="p">
<li class="fieldcontain">
<span id="${p.name}-label" class="property-label"><g:message code="${domainClass.decapitalizedName}.${p.name}.label" default="${p.defaultLabel}" /></span>
<div class="property-value" aria-labelledby="${p.name}-label">${body(p)}</div>
</li>
</g:each>
</ol>
so after much exploration coming up through templates, from the bottom I ended up right at the top with the '
so nearly there now. back into main.css that i'd copied in. if you edit that, down around line 215 you get this style. If you comment out the overflow property - its all fixed !
.property-list .fieldcontain {
list-style: none;
/*overflow: hidden; */
zoom: 1;
}
I tried auto, scroll, and visible but that seems to much about with too much of the page so best to just comment it out.
once you do that - the rest of the rendering of your forms starts to work !! blimey one line of css for all that pain. Attached is the page using
Lastly through out all this, id ended up digging through /tracing fields plugin. What a nest that is. Not really finished here, but basically
with no body just renders a label and no content. So you either need to provide provide a body tag, say to get the value field displayed.
as
if no widget template has been defined then the renderDefaultDisplay is called which again has very limited options for controlling the rendering by falling through a 'switch (prop.type)' and basically calls either g.format (bool), g.formatDate (but no LocalDateTime/LocalDate Support) or g.fieldValue, non of which are bootstrap enabled.
if you call
these two diagrams are not beautiful but just high level pseudo code walk through for what the core tags are trying to do. One day i'll try and pretty that up but it might help you if you get stuck
I'll raise a bug for the main.css clipping directly to the grails team and see what happens, but you can comment the line out yourself if you fall foul of it.
[Stackoverflow disallows the word help in the title. Hence the h3lp]
We are in the proces of moving our code from Orbeon 3.9 to Orbeon 4.x. One of the many things that changed is the behavior for display of xforms:alert and xforms:help. Example code:
<xforms:input ref="#code">
<xforms:alert ref="$resources/required-field"/>
<xforms:help ref="$helptext"/>
</xforms:input>
In Orbeon 3.9 the alert is displayed as a red img with a white exclamation mark that has the text as tooltip, only if the binding fails. The help is displayed as a blue-ish image with a question that activated a tiny pseudo window containing the (potentially large) help text.
In Orbeon 4.7 the alert text is displayed as-is, no image and no condition based on binding. This interferes with a carefully designed interface as it takes up a lot more space. The help text is not displayed at all because .xforms-help has display: none;. Overriding that doesn't work because the text would then just be displayed inline.
I could not find documentation for these changes. Does anyone know the rationale and how to make "alert" and "help" useful yet again?
There are two changes with Orbeon Forms 4.x which might be relevant to this:
The HTML layout of elements has changed a bit. This means existing CSS might have to be adapted. You can check this by comparing the HTML produced by 3.9 vs. 4.x for a given page. With 4.x, all form elements, for example, are wrapped within a <span> or <div> element.
Form Runner uses Twitter Bootstrap as a CSS library. But the Bootstrap CSS files are also included for non-Form Runner pages.
This said, "red icon" alerts should still work, see for example the good old Espresso Order or Bookcast demos.
If you see alerts inline and unconditionally, it means that somehow the proper CSS doesn't apply, either because of the HTML layout change mentioned above, or because some CSS files are missing.
Look at this post : http://blog.orbeon.com/2014/01/improving-how-we-show-help-messages.html
and this : http://discuss.orbeon.com/how-to-use-the-quot-new-quot-xforms-help-in-4-5-td4658348.html
julien
We make newsletters using the mailchimp service for a customer, now our customer would like to print the webversion of the mailings, but without the mailchimp top bar (#awesomebar).
Is there a plugin or something for firefox or chrome that can prevent an div from printing and that is easy to use for a non-technical person? So firebug is not an option.
I allready tried to contact mailchimp about it, but they won't change the print css.
Why not just disable the awesomebar in the first place?
If not, just use some custom CSS in your template. Add the class noprint to any elements they don't want printed, and then in your custom CSS, add below:
<style type="text/css" media="print">
.noPrint, #awesomebar {
display:none !important;
}
</style>
If this doesn't "exactly" work for you, hopefully you can use it as a starting point. The media="print" tag only applies when the browser goes to print - it doesn't affect the display of the page normally.
Is there a way to get struts 2 (using tiles) to build the whole page before sending it to the browser? I don't want the page to be build "progressively" in the browser one part at a time.
The main problem I'm trying to solve is that internet explorer 7 flashes/blinks the page even if only some of the content changes (firefox does this much more smoothly).
So that if I have a page with:
HEADER
some content
FOOTER
And the "some content" area only changes between page loads, the FOOTER part still flashes the white background before filling it with the background color of the footer. I tought that maybe by getting struts to send the complete page it would load fast enough to eliminate the "blinking".
Now the FOOTER comes from the server a little bit later than the parts before it and so it flashes (in internet explorer, firefox displays the page smoothly).
NB: this is an important requirement for the site, and using ajax to load the middle content is out (as are frames or other "hacks"). The site is built using CSS and not a table layout, maybe I will have to use a table layout to get it to work...
About using tiles flush parameter:
I tried that and it doesn't work as I need. I would need a flush-parameter for the whole page. I have tried the normal jsp page directive "autoFlush=false" but it didn't work. I set this directive on my main template page (and not in the tiles).
Here is an example from the main template, which uses header, body and footer templates. With the Thread.sleep() I added the problem is easy to spot. The footer renders 2 secs later than the rest of the page.
<body>
<div id="container">
<t:insertAttribute name="header" flush="false" />
<div id="content"><t:insertAttribute name="body" flush="false"/></div>
<div class="clear"></div>
<% Thread.sleep(2000); %>
<t:insertAttribute name="footer" flush="false" />
</div>
</body>
UPDATE
Thanks for the comments. The requirement is actually almost reasonable as this isn't a normal web page, think embedded.
But apparently there is no way of configuring IE to start rendering after some delay (like firefox has a configurable delay of some 100ms)?
I tried to intercept the TilesResult but the method doExecute is run before the whole content is apparently evaluated, so the method has already exited before the jsp is evaluated (my Thread.sleep() test). I was wondering how I could render the whole response to a string and then output that all at once to the browser.
I know that this isn't foolproof and network delays etc may factor in this, but if I could get the response to output all at once and maybe use a table based layout (IE possibly renders the table only after the table closes) this could work reasonably.
Or then try to get this switched to firefox or maybe forget all about this little glitch...
UPDATE 2
This started to bother me so I did some investigation.
If I had a plain jsp page (no tiles) the buffering works (with the buffer attribute), so that if I had my Thread.sleep() there the whole page rendered after two seconds if the page size was below the buffer size.
But if I used tiles in the page (as in the example above) I couldn't get the page to render at the same time (I even included the page directive in all my tiles-templates/"components", no help). So tiles probably flushes the response somewhere?
Furthermore, the "problematic tiles" was my body-part, which contained a struts:form tag. I replaced it with a normal form-tag and it worked as I wanted...
UPDATE 3
Ok, nobody seems to know the inner workings of tiles or struts tags...
No big problem as this is a very specific case and requirement.
I worked around it by using apache as a proxt in front of the application, and using apache's proxy configuration options to specify a large buffer.
I'll mark this as answered.
You can send page data all at once at the server end if you like (and many frameworks do that anyway for convenience) but the reality of networking is that it won't all arrive at once and the browser will render it as packets arrive. And this is a good thing for responsiveness, even if you* aesthetically would like the page to display all at once.
You can reduce the lag as much as possible by simplifying markup and using deflate compression to keep the payload size down, and that's a worthwhile thing to do in general. Plus you can make sure you're not hitting a Flash Of Unstyled Content. But you can't control when the browser chooses to render, short of doing it all in JavaScript with all the downsides that entails (and even then, the browser might redraw slowly).
(* - or your client/boss, if that's who has come up with this "important requirement" that your site somehow work differently to every other page on the web.)
Can you use the "flush" attribute on the tiles components?
<tiles:insertAttribute name="body" flush="false"/>
In addition if the output buffer gets too big, it will flush anyway. Try increasing the buffer size?
<%# page language="java" buffer="500kb" autoFlush="false" %>