I tried to use the localisation feature in ngx-bootstrap:
I used the exact demo from the documentation:
https://valor-software.com/ngx-bootstrap/#/datepicker#locales
Since i want to localize the date picker.
I get only 2 locales in my app 'sv' & 'en'.
Did anybody get the same behavior?
List locales shows only loaded and registered locales,
It's desired behaviour to reduce bundle size of your application
Eventually our date manipulation lib will be published separetly,
As for now datepicker locales demo contains all available locales
Related
We are working on a React application (using Create React App without ejecting it) and we decided to use Ant as our base component library.
Now that we are near the end of the project, we discover that the application will be integrated into a corporate portal (WebSphere) as a "portlet", so we inherit all the CSS files from the main page.
Both frameworks seem to have their own reset styles, but they use different values.
So far, I have not been able to find a LESS variable in Ant that can be used for prefix all Ant's CSS rules.
Has anyone ever tried to make them live together?
We don't own the parent development, we can only make change on the React part, so only things related to Ant.
We finally go with a specific CSS patch file, and we add rules when needed.
Not really perfect, but none of the suggested path did the job we expected.
Here you can see some of the default antd variables.
One of them is #ant-prefix: ant;. I think you can change it and apply different styles.
That is a tough one, and at the end of development no less!
As #froston mentions, and which you seem to have tried the #ant-prefix: ant; in addition to this you will need to se prefixCls as a prop on every component instance you create, which will definitely be an exercise in self-flagellation.
Even if you set a global CONSTANT and import and use this with your components, you still have to thread it through to all the places, and will need to be appended with the component name.
By way of example, the defaultProps for an anchor is prefixCls: 'ant-anchor'.
Hope this helps and good luck!
I have installed the latest Extension Library and am building an Xpages app with Bootstrap. Select 2 is not included in the current Ext Lib. It is included in Xpages4Bootstrap. While that is an excellent extension I am not sure if I really should include that just to get Select2 - unless there are other benefits. But how do I install Select 2 so it works with the Extension Library? I tried using the steps from this post but so far no luck. When I run the code I get
'JQuery' not found at [/select2.min.js.jss]
could had be an AMD loading problem. When I look at Github github.com/select2/select2/blob/master/dist/js/select2.js I see an AMD check at the beginning of the code. Just remove the AMD if then else and keep the latest else clause or change define.AMD by false
I am working on an application build on Dojo 1.4 and currently used on IE8.
When tried to run IE10 Compatibility view, I observer some X (to clear the data) are being show in the fields like dijit.form.Select. While in IE8 it doesn't display them
Please guide to remove them or what basically is happening
Thanks in Advance
If this is the same problem I just fixed then the question isn't referring to the IE10 "clear field" X. It's referring to a very large text "X" character that is displayed in the Select widget in addition to the options that are supposed to be there, making the widget twice as tall as it should be.
In my case it was because I was mixing the CSS stylesheet from one Dojo version with the API's from another. Check to make sure that your stylesheet and dojo.js versions match. For example, in my case the stylesheet was:
...href="//ajax.googleapis.com/ajax/libs/dojo/1.7.5/dijit/themes/claro/claro.css" media="screen">
while the script being included was
... src="//ajax.googleapis.com/ajax/libs/dojo/1.10.1/dojo/dojo.js"></script>
I blame the fact that I was modifying Dijit sample code without knowing what the heck I was doing...
I have TRAC 1.0.1 running.
For my tickets I would like to have a DueDate. Entering the DueDate should be done by using a DatePicker. Because it is convenient, and you can not enter wrong values.
I added following plugin to TRAC: http://trac-hacks.org/wiki/DateFieldPlugin
The description says, that it provides validation for custom fields and a DatePicker for Milestone and Ticket fields.
My trac.ini configuration file looks like this:
[ticket-custom]
duedate1 = text
duedate1.date = true
duedate1.date_empty = true
duedate1.label = Due Date
duedate1.order = 4
duedate1.value = DD-MM-YYYY
[datefield]
first_day = 1
format = dmy
separator = -
TRAC is now checking the input against the format. But what I really want is a DatePicker that pops up and lets me choose the date.
Any help is appreciated.
If the input is being validated but there is no datepicker it sounds like a client side JS / browser problem.
I just created a new Trac env, added the DateFieldPlugin, copied your [ticket-custom]
and [datefield] ini configuration and it seemed to work out of the box just fine. For example on /newticket I can see a datepicker for the Due Date field (using Firefox at least). Given that, all I can really do is give some more details which might help us debug your problem.
The datepicker is added via JavaScript. If you are running Trac 1.0 then you don't need to worry about jQuery or jQuery UI as Trac core now ships with these dependencies. You can see that by looking at the scripts tab in Firebug etc. when you are running tracd. Are you serving your own jQuery or jQuery UI scripts which might be conflicting? Are there any errors shown on the Firebug console tab?
The plugin serves extra JS files when you request certain pages in Trac, including /newticket and /ticket. You should also be able to see these scripts being served in Firebug etc. Is that true for you?
If you inspect the HTML in the ticket.html template displayed on /newticket you should also see something like this for the Due Date input
<input type="text" class="datepick hasDatepicker" value="MM-DD-YYYY" name="field_due_date1" id="field-due_date1">
Note the two datepick and hasDatePicker classes are what tell JS to to render a jQuery Datepicker dialog. Does your custom field have these classes? The plugin should be adding them for you (inside the post_process_request())
If all that is the same for you then maybe it is a browser problem?
While the plugin way was ok, when there was no other way, now it is only second best, because of all the limitations of storing date/time as formatted string instead of POSIX (micro)seconds, just like for other native Trac time fields.
There is a better way: Custom date/time field support has entered Trac core since 1.1.1 ("unstable" development branch moving towards next stable 1.2).
At least if you foresee heavy use and/or long term Trac deployment, you'll appreciate adding true timestamps to your db right from the start. It provides you with the best possible experience like date picker UI, full time zone and TracQuery support, even future time constraints ('nextday', 'nextweek', etc.) are possible right now.
A last note regarding Trac code stability: For what its worth I'm using true custom time fields support via patches in production since 2009 (Trac 0.13dev), runs smoothly in applications with 30.000+ tickets by now.
When I use my custom build of dojo, dojo.currency.format doesn't use the correct currency symbol.
This is the statement I use:
dojo.currency.format(1234.567, {currency: "USD"});
This is the result when I use the standard dojo release:
"$1,234.57"
This is the result when I use my custom build of dojo:
"ยค1,234.57"
How can I get my custom dojo build to produce the correct results?
I encountered this issue when first trying to use the dojo build. It has to do with the character encoding of the files. Check out the character encoding of an unzipped release (non source). Compare that to the character encoding of files in unbuilt source, and the encoding of files are a custom build. To see if this is an issue, (in chrome) you can force the browser to render the contents in a given encoding. You can try this to see if it is actually the issue you are having.
The easy solution to this (for me at least) was to set the charset on the dojo script tags
<script type="text/javascript" src="/path/to/dojo" charset="UTF-8"></script>
Dojo has a couple of pages on encoding that are worth taking a look at.
If you are using shrinksafe in the build, you may also need to specify the encoding there:
java -jar -Dfile.encoding=UTF8 shrinksafe.jar
Does your build have access to dojo/cldr/nls directory for the localization files of your locale? Check in Firebug whether it attempts, but fails to load currency.js from mentioned directory.