Is it possible to make the PrimeFaces's Editor component, right to left?
It seems not to support dir and style attributes... :(
in my experience controls in jsf framework like prime/open/etc.. don't support RTL using html #dir,
usually the interfaces of these controls are built using Javascript, so probably you should work at that level.
Can I suggest you to consider two other alternatives to jsf controls in this case?:
Using a javascript html editor (like elrte, maybe is easier to customize and it has also Arabic translation). http://elrte.org/
Using the Flex html editor (is Flash, if you can, and Flex support RTL for all controls)
F.
Just bumped into this thread by accident,
anyway I remember that i did the RTL with jquery like this:
<script type="text/javascript">
jQuery(document).ready(function($) {
$("j_idt33:inputtextlist").contents().find('html').attr('dir', 'rtl');
});
had to find the id with firebug , inputtextlist was the id i gave to the editor , and ypu can always use a smarter jquery selector (with suffix match)
Related
I am trying to change the p:growl position of primefaces through the .ui-growl class to use position: sticky. However, since the component is rendered at the end in body, the relative behavior of the position does not work as I would like.
Is there any way to use the sticky position for this component?
Or some way to get the component to render where it is declared?
PrimeFaces 5.1;
Mojarra 2.1;
Disclamer: I tried this with the PF 7.0 showcase, but I think the basics also work with the 5.1 version.
You effectively have 4 options. The latter three all need you to inspect the javascript source of the component (which is open, so you can ALWAYS inspect it before asking questions, the java source is irrelevant here) and for the first solution it helps to see how the component works, but inspecting with a browser developer tool is sufficient (that is how I did it).
Basic analysis with or without looking at the source
This is a variant on your "Or some way to get the component to render where it is declared?". Since on the client side, it is all plain html, css and javascript, you can manipulate with al tools available on the client-side.
You can see that the main part of the grow is html technically rendered where it is declared. Check the PrimeFaces showcase and you'll see
<span id="j_idt700:growl" class="ui-growl-pl" data-widget="widget_j_idt700_growl" data-summary="data-summary" data-detail="data-detail" data-severity="all,error" data-redisplay="true"></span>
right inside the form where it also is in the xhtml. The javascript of the component creates the client side dom things, amongst which is the container that you see right before the end of the body (from the showcase)
<div id="j_idt700:growl_container" class="ui-growl ui-widget" style="z-index: 1002;"></div>
This last piece is html is where the individual growls are added to when they need to be rendered and hence the part that makes the component in most normal cases behave correctly but needs to be done differently in your case.
Solution 1, pure client-side component agnostic solution
Effectively this is as simple as moving this piece of html in the dom, see How to move an element into another element?.
In the online showcase I put the following jquery code in the browser developer tool console
$("#j_idt700\\:growl_container").prependTo(".layout-content");
And added the following css
position: sticky;
top: 10px;
float: right; // this is needed in the showcase, might not always be needed
And it worked.
The jquery should be put somewhere in your page where it runs after the component javascript is executed, so best is to do it right before the end of the body.
Keep in mind that the j_idt700 prefix is the dynamic id of the form in the showcase (it does not have a fixed id here), but you can also use different selectors based on the classes or whatever)
Solution 2, changing the source 'locally'
In the javascript source, you can see where the container is technically rendered
render: function() {
//create container
this.jq = $('<div id="' + this.id + '_container" class="ui-growl ui-widget"></div>');
this.jq.appendTo($(document.body));
//render messages
this.show(this.cfg.msgs);
},
Changing the this.jq.appendTo($(document.body)); in some way to have it appended to the current html node ('this'?) will make it work too. Regarding the overriding, you have two options
How do I find and/or override JavaScript in Primefaces component based on widgetVar?
Override a method from a Primefaces specific widget
Solution 3 Changing the source server side
Effectively you do the first part of #2 but patch the source and create a new custom PrimeFaces version
Solution 4 Make this feature avaiable for others too
What can be done here is to create a new attribute on the component and patch the source in some places so it is configurable to have the component behave as it is now or as sticky (they changed the existing 'sticky' attribute to 'keepAlive' in 7.0.x so sticky is avalable again ;-)). Of course this should be submitted as a patch then...
I have used Bootstrap while development of Web Application. Now I have started learning of BootsFaces. While learning very first question pop up in my mind is
What is Exactly difference between Bootstrap and BootsFaces? and
what are their pros and cons over each other?
I searched for these answers but there wasn't any answer which make my doubt clear. Please help me for these questions.
BootsFaces is a JSF component library which generates HTML that uses Bootstrap. BootsFaces allows you to easily work with Bootstrap in a JSF application. Comparing them would be more or less the same as comparing red paint to a red painted board.
Some info from the BootsFaces showcase on this subject, specifically on layouting:
Why BootsFaces? Why not using Bootstrap natively?
BootsFaces takes full advantage of Bootstrap's Grid system while maintaining the benefits of being a JSF framework. Actually, we believe it's more concise and more expressive than programming Bootstrap natively. Convince yourself: inspect the source code of the demo in your browser's source code view. After reformatting, the form is 81 lines. The JSF source is is 45 lines.
BootsFaces being a JSF framework means that you can leverage Bootstrap's layout feature using - for example - the JSF templating system and JSF's conditional rendering to achieve and maintain very complex layouts without much effort.
This website is an example itself: it uses a page template with ui:insert and ui:include and the pages are ui:compositions.
See also:
What is the need of JSF, when UI can be achieved with JavaScript libraries such as jQuery and AngularJS
For last two years I have been programming extensively with jQuery and ExtJs. I think now it's time for me to invest some time in learning the impressive YUI library.
In terms of learning from scratch what is advisable?
I dont plan to use YUI 2 at all in any of my future projects I will use only YUI 3. Is there any paradigm shift in riting code for YUI 2 and YUI 3? or is it only about some cosmetic changes ?
YUI2 and YUI3 are really very different. As different as plain javascript vs jQuery.
Here's an example of setting the background color of all elements of a given class to red to illustrate the difference.
First in YUI2:
<script src="http://yui.yahooapis.com/2.8.2r1/build/yahoo/yahoo-min.js"></script>
<script src="http://yui.yahooapis.com/2.8.2r1/build/dom/dom-min.js"></script>
<script>
var YDom = YAHOO.util.Dom;
YDom.setStyle(YDom.getElementsByClassName('test'),'background-color','red');
</script>
Now in YUI3:
<script src="http://yui.yahooapis.com/3.3.0/build/yui/yui-min.js"></script>
<script>
YUI().use('node',function(Y){
Y.all('.test').setStyle('background-color','red');
});
</script>
Notice the main differences:
In YUI2 you include the needed modules yourself using the <script> tag. In YUI3 you only include one script file with the <script> tag and load all the rest using YUI().use. In the example above we use the node module in YUI3. YUI2 does have a module that can do the auto loading but it is a separate module itself and not built-in to the YAHOO global object.
YUI2 is traditional imperative programming: foo(bar()) while YUI3 uses chaining.
YUI3 forces you to write all YUI related code inside a function therefore running in its own scope and exposes only the YUI object to the global scope. This is basically ninja mode in other libraries.
Learn YUI 3, it is the future of the library. It's also a huge leap forward in terms of usability and flexibility from YUI 2. At this point learning YUI 2 unless you really have to is going to be wasted time.
Yes, definitely YUI3... It has great performance enhancements compared to YUI2.
Since you mentioned you have been extensively using jQuery already, this link might help you pick up YUI3 faster----listing the most frequently used YUI3-equivalents of jQuery modules
http://www.jsrosettastone.com/
Hope that helps..
For other people who flock to this page in search of answers, here are a bunch of videos from the YUI blog to get started on YUI3.
Eric Miraglia’s Welcome to YUI 3
and more videos here - http://www.yuiblog.com/blog/2010/10/27/jquery-and-yui-3-a-tale-of-two-javascript-libraries/
You can find more documentation on YUI3 library here http://yuilibrary.com/
YUI is a free, open source JavaScript and CSS library for building richly interactive web applications.
YUI is a library of JavaScript utilities and controls for building richly interactive web applications using techniques such as DOM Scripting, DHTML, and Ajax.
Fast
Modular Architecture / Dependency Management
Component Infrastructure
Event System
DOM Interaction,Ajax,Many Widgets
Great Documentation
YUI App Framework
Is Open Sourced
Is Developed by Yahoo and the YUI community
Is based on YUI3
Is inspired by Backbone.js
Gives you a basic structure for front end heavy web applications
More About YUI
I've been doing some searching around and couldn't find this topic anywhere. My company wants to use an HTML doctype but wordpress outputs XHTML by default. I've seen plugins and I would use these but this site will probably outlive the development of said plugins. Plus it's something else to account for when updating or building new sites.
If I use an XHTML doctype how will HTML5 browsers render it? Will they be backwards-compatible with old doctypes?
Edit 1: It is actually recomended that in order to make the transition to HTML5 easier that you try to follow the XHTML structure when writing any HTML.
There will be additional options and types with XHTML in HTML5 but a lot of it is based on the structure in which you are writing your HTML. The X simply means that it is moving to more of an XML base.
To go along with Kayla's input, you will want to make sure that all tags are being closed:
<br/> Instead of: <br>
You will also want to make sure to put quotations around any parameters:
Instead of: <a href=value></a>
Browsers have been slowly adopting the XHTML structure. This might mean that HTML that is formatted without end tags/etc might look a little different in IE 6 than in newer brower versions. Hope that helps!
It is not recommended to use the XHTML 1.0 or 1.1 doctypes for your HTML5 pages, one because its unnecessary and two your markup won't validate when you use the newer tags. Here is a quick guide on using XML syntax in HTML5 a.k.a. XHTML5.
Update: As noted bellow checkout the W3C Specification.
I am not sure what you are asking. What do plugins have to do with DTD?
Yes, any browsers that supports HTML5 is backwards compatible with (X)HTML, you can mix and match all you want. And basically as long as you are writing tags like:
<div>Hi</div> or <p>There</p>
instead of
<DIV>Hi</DIV> or <P>There</P>
the rest is just semantics.
HTML5 began life specifically because browsers manufacturers wanted to make sure that changes they introduced were backward compatible with existing web pages, in contrast to the now defunct XHTML 2, which was shaping up to be non-backward compatible.
So yes, your XHTML doctype will work just fine in HTML5 browsers.
As far as I know all modern browsers that are adding HTML 5 support will continue to support HTML 4 and XHTML for the foreseeable future so you should be fine.
If you're using Wordpress though stick with XHTML. It'll be supported for a long time to come in all browsers and most Wordpress plugins are designed to output XHTML.
I'm looking to implement an XForms Color Picker/Selector/Control (you know where it shows boxes or shades of colors in a dropdown type control).
Is it possible to do this in XForms (without using Orbeon; I am using XSLTForms)? Is so, how is it implemented, or can anyone point me to (simple) code examples that do?
The best approach will depend on what XForms implementation you are using. If Orbeon Forms, I would create an XBL component that encapsulate the YUI color picker:
http://developer.yahoo.com/yui/colorpicker/
If you're using the Firefox plugin exclusively, then you can create new xform extension components by wrapping any combination of HTML, JavaScript, XForms and XUL widgets in XBL.
This is probably the best resource I've found for Mozilla XBL xforms extensions:
https://developer.mozilla.org/en/XForms/Custom_Controls
In your case, probably the most efficient way to get this working would be to wrap the XUL colour picker component in XBL, ( https://developer.mozilla.org/en/XUL/colorpicker ) then write a little bit of JavaScript to link the picker's "onchange" event back to your model.