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!
Related
I'm building my first vue.js app and I'd like to have some help on deciding a design approach.
This app is going to be embedded inside a page of a site - built with Drupal 8.
Both app and site are going to use bootstrap 4 as base framework and we're going to use sass to style.
It's a quite simple app: a multistep form with some ajax call done to the aforementioned site.
It has anyway some components - one for each step, for some of the more complex input, for a sidebar showing the result of the ajax calls and so on.
I need to decide the "guideline" for styling this app and I'd like to get some help\insight to what solution is better.
On one hand, I could put the style inside the app itself; on the other hand I could leave all the style to the one present on the site.
As far as I can see the benefits of the first approach are the use of scope of each module, thus having a better "modularity".
However, putting the style all inside the site would avoid code duplication - simple example: custom color variables.
Personally I can't see for now other differences right now.
I haven't found material about the suggested approach and the pros\cons.
Could advice me of which approach is the best? Thank you.
It depends on the project, but you can make a list of cons and pros based on your project brief. If there are very few (or 0) changes in the future or it's based only on small components (not much style) then go with component-scoped styling. If the project is big, always go with a style pattern like the 7-1 pattern
I prefer working with the 7-1 pattern pattern.
Pros:
- Scalability or future updates like you mentioned the color variables case.
- You don't depend on Javascript to load the style, depending on how you write the app or how it loads, it may have glitches.
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.
First off, I'm brand new to Dojo.
I'm integrating it into our existing web app.
We initially only need the Calendar widget functionality.
I'm looking to keep the number and size of files as small as possible.
I don't believe downloading just the base code file will be sufficent?
http://dojotoolkit.org/download/
Additionally, the Dojo toolkit download is a huge zip (Even if I was to only use compressed files)
Am I left with downloading the toolkit and manually removing everything I don't need?
Is there no custom download builder like jquery ui?
Well, the dojo library is much larger than jquery ui and I don't know of an equivalent to the download builder. If you are just interested in using dojo for a single widget, you might consider exploring a different library.
To use dojox/Calendar, you are still going to need the many dependencies it has on other dojo modules. You can do this manually, but it will be tedious.
One thing you can do is run dojo's build system to package dojox/Calendar and all of its dependencies into a single file. This isn't a trivial task and requires a good understanding of dojo's AMD loader and package system.
If you want to go down this route, I would clone the dojo-boilerplate project on github. It contains everything you need to do this out of the box. Then follow the build system tutorial to understand how you set this up. From there you can have your app depend on dojox/Calendar to produce the file you include on your page to consume it.
I suggest that you put the whole thing (yes, it's a lot of tiny files) to your server.
Dojo 1.9 is written so that when users visit, their computers will only download the individual pieces on an as-needed basis. This is possible because every piece (AMD modules) is explicit about what it needs.
Once you have something that works, you can choose speed-up loading times by using the build system. Basically, this involves going: "If the user wants this thing, they'll probably want all this other stuff, so create a big minified lump and give it to them whenever they start asking." Best of all, it doesn't have to be perfect: If you miss including something, the users browser will still request it a la carte.
At work we're using the Dojo Boilerplate starting application which helps give some initial organization to the build process.
I am trying to build a CRM tool for a particular niche. I'm a complete newbie. This will be my first app. My only programming experience is with VB and MS Access, so RoR is presenting quite the learning curve. I have worked through the first version of Michael Hartl's Rails Tutorial. (And actually absorbed about 10% of it)
I bought a Themeforest bootstrap admin theme and have two general questions on it:
1) The theme has some PHP code in it. I'm assuming that I should re-write this code in Ruby, right? The code mostly controls things like file uploading, etc.--things that could be re-written in Ruby by an experienced programmer rather quickly (for me, it will take months :)
2) The theme contains a number of different pages. For example, one page is a dashboard, and another is a calendar. Both of these pages have a lot of duplication between them - all the main control buttons, etc., stay the same from page to page. In the theme, each page is a different HTML file where all of the code is simply duplicated. I'm assuming that I'll want to set up some sort of template system in Rails so that I don't cut-and-paste code between a bunch of HTML pages, right? (If I change a main button, I only want to make that change in one place, rather than in each of the 20 HTML files that came with this theme.)
1)
I'm not absolutely sure if there's no other way, but it's most likely the easiest solution.
If you have to rewrite stuff that's common in web apps, like file uploading, there is usually a gem to help you out, so you don't have to do everything from scratch. I can recommend the paperclip gem, Railscast for file uploading, since we use that in our own project.
Note: The Railscast is out of date, so the installation stuff is no longer accurate. Also, paperclip requires ImageMagick to work.
Railscasts also cover lots of other useful gems. If you need to find something specific, just google it. The github page then usually reveals if a gem is still maintained or if you're better off with something else.
2)
Rails prevents duplicated code with partials. Here's the Railscast (syntax might have changed since 2008). Partials let you place code like headers, or buttons in your case, in a file, which can then be rendered in any of your views.
Unfortunately, I can't link the other stuff like the github page and Rubygems.org because I lack the reputation. I hope this still helps a bit.
Extract the common elements of the theme into your application layout.
Extract the modular sections of the theme into their own controllers and actions. For example, create a calendar controller for the calendar section, the actions that appear in the calendar controller will be the views that support the calendar. You can also use partials (views that start with '_'), without having to create a controller action. But if there is data that needs to be sent to the view, it is better to stick with normal controller actions and views.
As for the php code, get rid of it, move as much logic as possible into your model and controllers, with preference to putting in your models. As hobo suggested, check out gems to replicate the functionality of any complicated php code.
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