I've not programmed this before and I'm not finding any examples in searching of how to implement this Dojo.
I need a field to type ahead as a drop down field and will fill in the field as they type so when they type enough characters for their needs, they can hit enter and it grabs the correct value. My view is over the 64K limit. The field I've programmed, when previewing in the browser, doesn't show the field, only values in a huge long list below it. Can someone shed some light on how to program this field? Thanks for your help.
Is there an reference book that give examples of all the various elements of xPages that go into more detail than, for example, loading a drop down with six values.
Is this the Dojo Filtering Select Extension Library control? If so, XPages Extension Library book covers those components. Mastering XPages 2nd Edition covers the core controls and generic XPages runtime topics.
Without code or more details it's hard to tell what the cause is. It sounds like the relevant Dojo classes aren't loaded. That could be because the theme used is Bootstrap, which is jQuery-based rather than Dojo-based. Alternatively, if you're not using the Extension Library control, the most likely cause is declaring the Dojo Filtering Select but not including the relevant Dojo modules. That's again one of the reasons to use the Extension Library components instead of manually coding them. Alternatively you may be using a modern IE browser against an older Domino version - IE doesn't support older versions of Dojo, requiring compatible browser / server versions.
Related
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.
We write a lot of intrasite modules and are noticing that they really deviate now in SF 4+ from the content-based ones. So, on that note, I have some questions:
How do you get the EXACT look and feel of the standard modules for the edit/create form? For example, how do you eliminate the menu above, center the form, etc, as in, say, the Events module?
How do you add an actions menu dropdown to a radgrid, same as you'd see in the grids for standard modules?
How do you incorporate Sitefinity fields into the usercontrols? For example sf:ImageField throws script errors when added to a control? Also, is there documentation on each of these fields and how to configure?
---finally---
If we really want that standardization, do we have to go with another module type?
4.Is there a module type that will allow us to access non-sitefinity data (ie separaate db
but also provide us with exactly the same functionality and UI experience as the content-
based modules?
intra site modules are simply custom user controls (ascx) placed into backend pages to add your custom functionality to the backend. To copy the look and feel of the rest of the site, I literally copy and paste the HTML into the control.
I did a webinar on this a while back, including code to recreate the backend editor. It appears to still be valid, and is available here: http://www.sitefinity.com/blogs/joshmorales/posts/josh-morales-blog/2011/06/30/sitefinity_intra-site_module_webinar_notes
the centered view is a bit different, and I don't have that html, but you could potentially do the same (copy it from another native page). I don't always get it 100% accurate (my controls are usually laid out different from what Sitefinity does) but I get close enough so that it doesn't break the user experience.
The actions menu could be recreated with javascript, but if you are looking for NATIVE integration that does all this for you, indeed you would be looking at inheriting or much better yet: simply using the module builder, which lets you build custom types that automatically install themselves into Sitefinity as if they were regular modules.
Fields are definitely designed to run inside the context of native sitefinity module definitions (the classes that make up the UI using the Sitefinity context). This doesn't mean you can't include Sitefinity content in your modules; it simply means if you do you'll have to implement the integration yourself using the API.
On your last question, the only way to use external data but still keep the "Sitefinity Content" UI is to inherit from Content, then create a custom provider that reads from your database and translates it into the Sitefinity content type. It is certainly possible, but is quite a big project.
Unless you are in full need of this tight integration, I recommend simply going intra-site, linking to Sitefinity content types,taxonomy, etc through the API and manage it separately.
I hope this was helpful!
I'm looking a Dojo based calendar that can display events spanning across days in a month view exactly like the JQuery plugin FullCalendar
I work primarily in Dojo and I don't want to load JQuery if I don't need to.
This thread is a bit old now but I wanted to raise that there's now a candidate widget written by me for dojo 1.8+ that does exactly what you need: https://github.com/damiengarbarino/dojo-calendar
I tried to use the dojoc project and finally developed my own widget.
It is heavily customizable, has mouse, keyboard and even touch support, right to left display support, date formatting, custom views etc.
Documentation is available at: http://livedocs.dojotoolkit.org/dojox/calendar
I've been searching for something similiar recently and the best I can find is the 'dojoc' library. It appears to have been apart of the full dojotoolkit at some point but I can't seem to find a whole lot of information on it.
A test page showing it is on the author's website here. The github page for it is here. So far my attempts to locally use it have failed miserably. It seems to be built against an older version of dojo as well since it hasn't been updated in a while.
Although the Dojo 1.8 calendar widget looks promising, the documentation linked here http://livedocs.dojotoolkit.org/dojox/calendar is not up to scratch. Possibly the widget itself is also not ready for general use.
For example, it is proving difficult to prevent a particular event from being edited.
I realise 1.8 is not out yet. I trust the calendar widget and documentation will be better by the time 1.8 is released.
I want to build a custom CMS where users a Rich text editor is the main way to create content rather than wiki markup.
Besides stability and performance, I want the RTE to be easily extensible. The latter point is very important because I intend to extend it to my needs.
For example I want the users to be able to embed OpenSocial gadgets and whiteboard (based on canvas) into the page. I also the want the users to embed media source like (youtube, slideshare etc).
My preliminary investigation shows that Dojo's (dijit) RTE and TinyMCE are pretty good. How would you compare the two in terms of stability, performance and extensibility. Any other RTE's I should be looking at that fit the bill?
PS: I am using dojo as the main js library.
Hava a look here (blog post with some very helpfull informations).
My own opinion is that there are two free available rtes that are close to each other in comparison. Those are CKEditor and Tinymce. My experience lies on the tinymce side and i can say that the extensibility using own plugins is great with it. Some independent tests have shown that tinymce seems to be more adavanced than CKEditor, others claim CKEditor is better. You will have to decide on your own (development is advancing further each day and new functionality has been developed since those tests).
You may also have a look here for comparisons and discussions:
http://verens.com/2007/09/27/fckeditor-vs-tinymce-vs-everything-else/
http://verens.com/2007/09/27/fckeditor-vs-tinymce-vs-everything-else/
http://www.mediacurrent.com/blog/wysiwyg-shootout-and-winner
I have a web app for commercial property management that needs spreadsheet-like functionality for doing budgets. I don't want to use Google Sheets because my users won't necessarily have a Google account.
So is there anything out there that I could use?
I looked and could only find SocialCalc which wasn't quite good enough for me.
Options:
ExtJS Grid Component (Open Source[GPL3] & Commercial License)
Infragistics Grid Component (Commercial License)
TreeGrid (Commercial License, Free Version has maximum of 33 rows)
If you don't mind implementing the logic yourself, the ExtJS grid component is a JavaScript grid component with lots of powerful features, and it is available in both open-source and commercial versions.
I have used dhtmlXGrid successfully. There is an open source version that you can use freely to get your application developed. Assuming everything works out, for $200 you can purchase a license for it and distribute it with your application.
Very easy to use; create an HTML table structure with your data in it and then bind dhtmlXGrid to the table - it automatically turns the table cells into editable fields.
Check it out here: http://www.dhtmlx.com/docs/products/dhtmlxGrid
Again, you will need to implement the spreadsheet logic yourself but dhtmlXGrid makes it straightforward to translate that into an editable column/row display.
There is an excellent grid from Farpoint
They have web and win forms grids available and are not too bad price wise
Infragistics has spreadsheet-type functionality in their data grid product
You may want to give a try to treegrid # www.coqsoft.com .
try telerik radgrid. It is a pretty decent .net user control which can easily render an XML datasource for user editting. Its also fully Ajax enabled to avoid delays when entering volumes of data.