i'm using primefaces to generated some barcodes (in cod128 format), the primefaces tags works pretty well but the client want the output image (with the codes) at some specific size (1cm of height and 8cm of width), so that's the question:
How i can show a fixed output of the generated barcode at some specific size?
Here is some snippet of my code:
<h:body>
<p:panelGrid columns="2">
<h:outputText value="Code128" />
<p:barcode value="0123456789" type="code128"/>
</p:panelGrid>
</h:body>
i'm using this for reference: http://www.primefaces.org/showcase/ui/multimedia/barcode.xhtml
Thanks :)
The primefaces tag allows you to change the width and height of the component:
<p:barcode value="0123456789" type="code128" width="Xpx;" height="Ypx;"/>
since the size you need is "cm", I would suggest you look for a converter on the web.
You can control and fix the output's size by using the dimensions' attributes of <p:barcode>'s tag, so that you don't need extra CSS/JS improvements :
<p:barcode value="0123456789" type="code128" height="38px" width="302px" />
Related
I would like update a chart size with the change of the browser's window if it's possible.
It is my code:
<b:column col-xs="12" col-md="12" >
<p:chart widgetVar="foo" type = "pie" model="#{graphicBean.pieModel}" rendered="#{not empty graphicBean.pieModel}"/>
</b:column>
The <p:chart> supports responsive mode. Set it to 'true'. The following line is from Primefaces documentation.
In responsive mode, chart is redrawn when window is resized
<p:chart type="line" model="#{chartView.lineModel1}" style="height:300px;" responsive="true"/>
Please refer this for an example.
I'm trying to show the following text on the footer of my table:
Showing 11 to 20 of 51 entries
But I can't find a way to do it. I didn't find any vars in the footer that give me those variables easily.
I also tried to create a class that inherits from ExtendedDataModel and kept the values there.
I got the number of the row from the sequenceRange in the walk method. But, apparently, the footer of the table is rendered before the walk method being called, which resulted that the info on the bottom of my page was outdated by one request.
Any suggestions on how to do this?
By the way, I'm using JSF 2.1 and RichFaces 4.3.0 Final.
You can use the built in datascroller feature of rich faces:
Update 1
The scroller has a default layout which you might not want. But you can customize it. see Scroller Facets Usage tab in this link. Copying here:
<f:facet name="pages">
<h:panelGroup>
<h:outputText value="Page "/>
<h:selectOneMenu value="#{dataScrollerBean.scrollerPage}"
onchange="#{rich:component('ds')}.switchToPage(this.value)">
<f:selectItems value="#{dataScrollerBean.pagesToScroll}" />
</h:selectOneMenu>
<h:outputText value=" of #{pages}" />
</h:panelGroup>
</f:facet>
Refer this link:
Datascroller
This example shows the number of rows in a datatable in datascroller based on size mentioned in rows attribute of dataTable.
Is it possible to have items in a rich:dataTable display with a different icon depending on their #{bean.type} similar to how you can alter the icon in a rich:tree and rich:treeNode?
you can add a <f:facet name="header"> in your rich column that can display any HTML, or in your rich column you can have any html which could be custom images.
you can add a rendered attribute to <h:graphicImage> based on the value of #{bean.type} or #{bean.type} could be a link to the image for to get.
for example
<h:graphicImage value="/images/icons/tables/down_icon.gif" rendered="#{carsSortingBean.sortsOrders['mileage']=='descending'}" />
<h:graphicImage value="/images/icons/tables/up_icon.gif.gif"
rendered="#{carsSortingBean.sortsOrders['mileage']=='ascending'}" />
So yes. There are lots of way's to customize the output of a dataTable
So, like the title says in my case height of the extendedDataTable doesn't work, so my table also doesn't scroll because all rows are shown. I'm using richfaces4.0-final version. So here is my piece of code:
<rich:extendedDataTable
value="#{advancedSearchView.criteria}" var="criteria"
height="50px"
selection="#{advancedSearchView.selection}" id="table"
selectionMode="single">
<rich:column id="criteria_row" filterBy="#{criteria}" filterEvent="onkeyup" width="500px">
<h:outputText value="#{criteria}" />
</rich:column>
</rich:extendedDataTable>
AdvancedSearchView is request scoped bean, and criteria is an array of Strings.
I hope that is enough information. Thank you in advance. A would really appreciate if someone gives me an answer, because I'm struggling with this for a while.
According to the RichFaces 4 VDL (View Declaration Language) documentation, the <rich:extendedDataTable> component does not support the height attribute at all.
Your functional requirement is however understood. You want to render the extended datatable with a height of 50px and make the table body scrollable. You need to achieve this using the usual CSS means by style attribute which can take inline CSS declarations, or by the styleClass attribute which can take CSS classes, like as on almost every other JSF HTML component.
So, with style
<rich:extendedDataTable ... style="height: 50px;">
or, with styleClass (which is also the more recommend practice; separate style from markup)
<rich:extendedDataTable ... styleClass="criteria">
and this piece in a CSS file which you include by <h:outputStylesheet />:
.criteria {
height: 50px;
}
I have been trying to incorporate RichFaces into one of our more complicated pages to make it run a bit more smoothly via AJAX. Everything is working fine and it has solved a few problems I was having using regular form posts so I'd really like to keep it. The only problem in my way is that after pressing an a4j:commandButton most of my h:outputLabels are shortened by 3 pixels (these pixels were to the left of the text, which is unusual since the left padding, margin and border width are all 0px). This causes lots of my controls to shift slightly and looks very unprofessional. It looks to me like the re-rendering has done a more accurate job than the initial render. Here are the relevant parts of my page:
<a4j:form id="mainForm">
...
<fieldset id="illustrationDetails">
<h:outputLabel for="product" value="Product" />
<h:selectOneMenu id="product" value="#{illustrationManager.illustration.product}" valueChangeListener="#{illustrationManager.illustration.setProduct}" onchange="submit()">
<f:selectItems value="#{illustrationManager.illustration.products}" />
</h:selectOneMenu>
<h:outputLabel for="paymentFrequency" value="Payment" />
<h:selectOneMenu id="paymentFrequency" value="#{illustrationManager.illustration.paymentFrequency}">
<f:selectItems value="#{illustrationManager.illustration.paymentFrequencies}" />
</h:selectOneMenu>
<h:outputLabel for="expenseGroup" value="Expense Group" />
<h:selectOneMenu id="expenseGroup" value="#{illustrationManager.illustration.expenseGroupId}">
<f:selectItems value="#{illustrationManager.illustration.expenseGroups}" />
</h:selectOneMenu>
</fieldset>
...
<a4j:commandButton id="calculateButton" value="Calculate" action="#{illustrationManager.calculatePremium()}" ajaxSingle="true" reRender="mainForm" />
...
</a4j:form>
In the fieldset above, all but the first label exhibit this problem. The first label is rendered what I would consider to be correctly (with no pixels to the left) by the initial render and as a result is not changed by the re-render.
Any suggestions would be welcome! Also, if you want more info like the css for the relevant controls let me know and I'll post it.
Well, this is a partial answer anyway. The 3 pixels to the left of the h:outputLabels was due to the fact that the Mojarra JSF implementation adds a \n character to the beginning of the label tag body it creates. I'm as baffled as the guy who submitted this bug about it as to why this is done. The \n is converted to a space when displayed and that's what my 3 pixels were.
I do not know why, but the re-render triggered by my RichFaces AJAX call removes these \n characters and so the space is no longer displayed.
As a workaround, I have explicitly put spaces at the front of all my labels so that a space is always displayed. I'm surprised this is not a common problem.