Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am attempting to create some visualisations in Drupal, and found the D3 module. However, I can't find much documentation. Could someone point me in the direction of a guide to using the module, or explain how to use it?
I have installed the module as described here, but I don't know how to get a chart to display on a page (I haven't used Drupal much either).
Basically I would like to know:
How does it work with Drupal?
What all Chart styles does it support?
How does it integrate with Drupal's Views and Panel in terms of generating visuals?
Thanks.
The d3.js module indeed seems to suffer some documentation issues. Moreover it still doesn't have an official release so far (only dev versions). The
d3.js library that this module integrates with seems to become more and more popular.
Refer to the Maintenance Scorecards for over 20 criteria to consider when selecting a module to create charts. By doing so, you might want to consider other charts related modules that can be used for creating charts in Drupal.
The number of reported installs indicate that either the Chart module or the Charts module is often considered as a viable module for creating charts in Drupal. For both modules quite some documentation is available also.
The Chart module's project page contains some information that indicates it is "being depreciated and users are recommended to move over to the Charts module". Though most recently some comments in the chart issue queue contain some details that illustrate that that depreciation is being reconsidered. Refer to that issue queue for more details on that.
If needed, do not hesitate to create an issue in the module's issue queue. As an alternative create a new question on this site (or Drupal Answers) and find a way to let me know about it (eg via some comment in any of my questions or answers around here).
Disclosure: I'm the maintainer of both modules Chart and Charts, and the author of the documentation of charts related modules mentioned in my answer also.
Note: In a future release of the chart module, support for the d3.js (as a charting library) is expected to be added also.
I have downloaded the latest version of the library d3.zip in /sites/all/libraries/d3 and installed the module. Once it is enabled (D3, D3 Views and D3 Examples), you can see in yoursite/examples some examples for the module. With "D3 Views" enabled you have the possibility of setting the format "D3 Visualization" in a view. You can use the view in your page.
Before I have worked creating some graphics with the module forena and the library SVGGraph. It is very well documented.
With d3 I have just started today testing but I got to create a graphic in the view how I told you above.
Good luck!
I have been working with this module myself, lately, and hope to have a live example up soon. As user28577 posted above, you should be able to use D3 Views (following the instructions) to create a view to display one of stock options (such as a bar or pie chart). Depending upon your knowledge of using Views in Drupal, it should be fairly easy to either create a new content type, or use an existing one as a source for your data that will be charted using the D3 module.
One possible reason (since I can't see your issue) you may not be seeing content is how your theme loads external JavaScript. I found this by toggling through different themes in one of my test environments, where some would not load D3 through an external library. Once I downloaded the latest build of D3 and placed it in sites/all/libraries/d3, things worked fine. It also allows development without an internet connection.
Without a good knowledge of the Drupal API, it can be challenging to source your data to chart if building a custom visualization. Although it's not the "Drupal Way", one workaround may be enabling the PHP filter (part of Drupal core), and posting your visualization into an existing content type, such as a basic page. You should be able to view this fine. But keep in mind that all data must be edited manually, and be aware of possible security holes.
I know this is an old thread, but I'd like to add a few things for people continuing to read this.
I apologize for the 'work in progress' documentation, but the
module itself has been a 'work in progress'. The module is now in
alpha1, and so documentation is in the works.
The module takes a completely different approach to
visualizations then that of modules like charts, and
chart. In terms of the API itself, those modules take a more 'php in, js out' approach. That is to say, you build the visualization primarily in php, and the module will handle all the JS for you. What the d3 module does is let you add 'libraries' via the libraries module, which are actual d3 code snippets wrapped in some code that Drupal reads. You can add and remove them much like modules. You can also make libraries dependent on other libraries. These give module developers and d3.js developers the ability to customize and add in any d3.js code because it's not baked into the module. The downside is that there is a little less 'out-of-the-box' magic.
These libraries also have .info files which can contain mapping information to take data from views, for example, and map that data into your d3 drupal library. You then customize that mapping in the views settings.
There are a few libraries that ship with the d3 module, but there will soon be a few larger and extensible repositories of libraries that are Drupal-ready. The idea is that there two huge communities - The Drupal community that builds thousands of modules for use, and the d3.js community that builds thousands of visualizations for use. Those will meet together and all of those libraries will be ready to add to a Drupal site just like you would a module.
Clearly documentation for the D3 module is a "work in progress". You can view the progress here, but it looks like you will need to rely on trial-and-error and results from other community members.
Basically D3 modules provide UI reach visualization of following types
Chord Digram
Force-Directed Graph
Treemap
Scatterplot Matrix
Bubble Chart
Pie Charts / Donut Charts
Multiple Line Graphs
and few more
Through library D3 gets well integrated with Drupal at presentation as well as Business layer. It is always much ahead than Charts module in terms of its styles and usability aspect.
D3 also avails VIEWS style formatters which can applied on the data manipulated through VIEWS and PANEL modules.
Even Visualizations build through D# and Drupal can be available for the DOWNLOAD apart from presenting onto the page.
Please visit - YouTube Video for further information.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
in my Qt application I'd like to output PDF-reports. The reports should be slightly modifiable for a particular customer. My idea was to create PFDs using QPrinter from rendered QWebkit-view. Rendered QML could also work. Looks for me as a very easy was to create PDF-reports with very flexible layout customization (CSS/HTML or QML) and without the need to learn/introduce additional software-package into the project.
Is someone aware of such an implementation already? It should be Open-Source (free or commercial)?
My wish-list is :-)
It should be able to display images preferably provided from
client-application as QImage/QPixmal.
It should be able either to
accept all variables as QMap or query values from a Postgres DB.
It should be either embeddable as code or linked as a library
EDIT
already checked:
QtRPT - pretty experimental and unmature. Many magics, comments in Russian in code.
NCReport - Open-source code is too old, last update 2007. Doesn't compile with Qt4.8.4. New versions are provided under commercial licenses. Commercial version looks very mature, has good documentation (ca. 100p), However I'm looking for a software which renders html/QML, so we could order a HTML-developer for creating/maintaining reports.
I dont think there is something ready made exists, otherwise it would be well known, because an issue itself pretty common. As a previous answer I also wrote my own generator. It's not open source, thought.
Problem is not only in printing (as being mentioned in previous answer). It can be more or less solved as soon as you can split whole report into pages yourself. Then you can render report content with headers/footers/page numbers/etc on 'per page' basis and print them separately.
Main problem is that it's easier up to me (having in mind all options Qt provides) to develop nice report generator for particular software, rather then trying to develop something very generic. In this case you have to either limit yourself on features you can use in the report OR introduce a lot of 'magics', certain assumptions/conventions etc.
You can make some kind of generic code for some cases then your reports all have similar structure (for example - header - first page header - main table section- footer with page numbering and all other pages the same without first page header), and then it's fairly simple to make an algorithm which will nicely split you main table section into pages.. but it's all gone as soon as you start think about more complicated scenarios with graphs etc.
An engine I've done based on JS and operates using basic reports primitives (like table, graph, label) which have some layout properties and actually JS code places them on a final report. Some reports primitives can be automatically splitter between pages some not..
I have made that kind of report generator using QWebKit (Qt version 5.1). It is not open source, though.
The biggest problem is that WebKit (or any browser's layout engine that I tried) does not work very well with printing. CSS standard covers printing, but the layout engines do not implement that stuff, or implement it only partially. So if you want features like headers and footers, page numbers, support for multiple paper sizes and support for both landscape and portrait, you have to do a lot of googling and testing. Almost nothing works as expected, so workarounds need to be invented and ugly hardcoding done.
So you can make a report generator using QWebKit. It's not going to be fun and new versions of Qt and QWebKit will most probably break something. So I would recommend making the report generator a separate application so that you can use different Qt versions for the main application and the report generator. At least design the report generator so, that you can separate it from the main application later if needed.
Has anybody implemented an instance d3.js in drupal 7 successfully?
I plugged in the main d3.js libraries into the page header without problem... but I get all sorts of errors when I try to put code that actually draws something into a page or block...
Somebody managed it with protovis a couple of years ago... http://drupal.org/node/516282#comment-2232740 and i was trying to work along the same lines.
A module package something like the one for http://drupal.org/project/thejit would be a big timesaver.
Thanks for any clues/guidance/examples!
There is a conversation in progress at Drupal.org about this.
And there's a sandbox module in progress that can be grabbed at
git clone http://git.drupal.org/sandbox/asherry/1477334.git d3
D3 is amazing!
A stable D7 module is probably 4+ months away but you never know.
Here are some contributed module suggestions for D7, which may help to use the D3.js library in a Drupal site:
Charts and Graphs (Official release available).
Charts and Graphs is an API for developers. It can be extended by third-party modules that want to add their own charting implementations. It does nothing by itself. It should only be installed if some other module requires it.
D3 (Alfa release only)
creates visualizations as libraries (alpha version only) which allows one to add/remove visualizations, share them between modules, and integrate them with (for example: Views) through library .info files.
The Basic module configuration presentation provide a short intro about how to use the module in combination with Views.
Forena (sandbox only)
Refer to issue # 2383509 for more details.
Knowing what errors you get would definitely help us help you.
One hint : you have to be careful about the way you add your script to prevent namespace problems. Another important thing is the scope your library is using (JQuery, $, etc.) as Drupal includes its stuff in a specific way.
The conversation posted by #ted.strauss is now closed: it is possible to have D3.js directed layout as an engine for graph_api.
The main page for the project d3 for drupal, by asherry is https://drupal.org/project/d3.
As far as I'm concerned chart integration (which doesn't need graph_api but is directly managed by d3 module) works very well.
I'm looking to see if anyone has any resources or tips for developing basic Drupal modules faster? Have you come up with anything to make your Module development faster?
The Drupal module documentation is kinda hard to understand and pretty massive. I'm wondering if anyone has simplified it and given techniques/tips for getting specific things done quickly. I'm currently looking for Drupal 6 and 7. Any help saving time will be greatly appreciated :-)
In general, I'd recommend picking up a copy of the Productive Programmer. There's nothing earth shattering in it, but there are lots of small tips that can increase your productivity incrementally.
For Drupal specifically, Pro Drupal Development and Pro Drupal 7 Development, though not focused strictly on speed of development, are indispensable.
Beyond that...
in the first place, if you don't have to, Don't Write Code
get familiar with the most commonly used hooks
learn to use Drush and Drush Make
learn to use Devel and Theme Developer modules
use the Schema module to generate your module's schema code, based on an existing table
use the Data module (+ this patch) to generate the code to expose your module's tables to Views
use the Form Builder module to generate form code
use Coder to learn the Drupal coding standards, which will help others help you
set up "quick searches" to allow you to quickly search api.drupal.org
learn the shortcuts in your IDE or text editor (I like Netbeans partially because of the Drupal plugin); print out a good cheatsheet
learn to use version control effectively
Well, there really no fast track to it. If you understand the Drupal API regarding module development (install, menus, blocks, forms, etc) you will grasp it. The hardest part I remember was wrapping my head around the menu system.
One thing that helped was taking simple modules and seeing how they worked, and problem solving my own solutions. Reading Pro Drupal Development helps too.
You basically need to have an understanding where to look (API function, hook, system... ) when you want to do X. There is really no need to memorize all hooks/functions in detail with all the arguments and stuff. That's something you can easily look up. Especially if you're using an IDE with I suggest (Using Netbeans myself).
Especially when you're altering stuff, try to develop some techniques to quickly figure out what code is responsible for the stuff you want to change. One example is to look at the hook_menu() definition of the module that does it and then check out the page callback and skim through the code. Things to look up: Are there hooks you can use, is it a form (if yes, what is the form_id, how is the form structured) and so on.
The best and maybe only way to get there (knowing where too look) is exercise. Every time you do something, you'll be faster the next time when you have to do something similar. I think what also helps is working on core/contrib modules together with others. You not only get to learn these modules better, you also learn how to read and understand code written by others better and you improve your own coding style.
Try to utilize proven, generic "building block" modules like Views, Flags, Panels, CCK/Field and so on. Then, the heavy lifting is done by these modules and you only need to provide the glue code to properly integrate them with your site. Might take a bit more time the first time you use these modules but you will likely save a lot time after that.
That having said, I'm not sure if the goal should be to build modules fast. I'd say the goal is to build modules better. Try to make them generic, secure, flexible, theme-able and so on with the goal to re-use these modules on the next site your building, when you need something similar.
The majority of basic drupal module development is copy and paste. If you use textmate, the Drupal bundle for it allows you to build up key bits of modules (menus, theming functions etc) just by point and click (as it contains most of the necessary code snippets; you just fill in your info).
Following the module building tutorials is good too; the truth is, if you spent 3 or 4 weeks doing it day in day out, and you already have some background in coding, you'll be just fine.
Gedit for Drupal will preconfigure the very good Gedit editor/IDE for you.
For example, a new module: create an empty module file mymodule.example. Enter that file.
module<tab> And it expands into a full, predefined module.
Or in any module: hook<tab> to see a list of available hooks. Choose e.g. menu<tab> and it expands to a full predefined hook_menu. With <tab> you can walk trough all the variable parts in that new hook, to fill in the details.
Drupal.rb Has a.o. a $ drupal generate module "modulename" command that opens an interactive shell, wich allows building scaffolds for modules. The templates from which these scaffolds are built, are overridable.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am a novice for both concrete5 and drupal however I have been looking at Concrete5 and Drupal. I am looking to create a web application that needs to be extensible. Client requirement will start from basic content management and it will need to extend to workflow based web application. I have been looking at the architecture for Drupal and Concrete5. For those who haved used either one which one would you recommend? Thanks in advance.
My two cents... Concrete 5 is far superior to Drupal.
I have over 25 sites using C5 right now. I have had 4 drupal installs in the past and have converted all of them to C5. I have also used Joomla, Expression Engine and PyroCMS extensively.
When I first started using C5, there were some great advantages for my customers in terms of end user updates to pages. It is FAR more simple for an average non-tech user to update content. This was a major win in my eyes. Most users were struggling to update content with the other options because it wasn't fluid or as WYSIWYG. The inline editing of C5 is outstanding.
That said, it was also very easy to convert HTML into templates using the tagging commands of C5. So in no time at all, I could take a site that was static HTML or PHP and convert it into a C5 instance. Again, very simple.
Within the last 6 months or so, I would say the extensibility has increased dramatically. New modules are added to the marketplace nearly daily. Some are FREE and some are paid, but I think ALL of them are cheap for the functionality and worth it. Most are $20 in that range.
If you know PHP well, you can write your own modules easily and not have to pay a dime and also not worry about the C5 core upgrades. There are lots of mechanisms built in that help developers take advantage of the system without having to worry about getting lost in software upgrades. This was another great advantage, that has cost me in the past with other CMS platforms.
In summary... Concrete5 is a top-notch CMS that is widely extensible with a ton of functionality that is super easy for anyone to use.
I've been using concrete5 for about 2 years now and I can wholeheartedly recommend it. Drupal is more powerful, but the amount of work that needs to be done to get to the starting point that c5 gives you right after install is huge. The concrete5 core provides you with a whole lot of stuff out of the box, and adding further functionality is straightforward with its comprehensive (although not always terribly well documented) API and active forums.
In terms of downloadable addons, there are many which cost but I've found that in many cases it's simpler to pay what is normally a low sum to get the functionality I need than to spend all the time (and time = money) coding it myself. Those situations where I've had to code a solution have been pretty painless - any trouble has been my failing, not the CMS'. Hooking into the core is really easy, including adding Dashboard pages for particular functionality (there's a helpful howto from Andrew, the core dev, on the site which explains how to do it).
Of course, the trump card is users' ability to edit their sites without having to understand UI 'metaphors' and 'paradigms'. It just works. You go to the page, click edit, and type away. Simples. My experience with pretty computer-illiterate clients has been very positive indeed, and I feel genuinely confident when I tell new prospects that they can expect to learn how to edit their site in 5 minutes.
I have been using C5 for over a year now. The core team for C5 is committed to making it better and better every release, and they often implement contributed Code....but the thing I like most over say, Joomla, is that the directive of the CMS doesn't change. while it is open source in that solid community contributions that line up with the overall vision will be included, the core team (original developers) oversee all aspects of the code. So it's more carefully comed over than other "community driven" CMS's.
There is a huge community involvement and help in everything from getting started to deep programming.
And above all other things...Clients pick up using the C5 dashboard in minutes. You'll be lucky to get that in most other CMS's.
I have enough experience with to confidently say that it is pretty extensible. There are modules for most common things that you would want to do. If there isn't you can always create you own module. Downside is that the learning curve can be a bit overwhelming at first. Drupal's UI had been lacking but it's been improved with Drupal 7. But it also benefits from a decent sized community.
I also dabbled a bit in Concrete5 and was impressed with it's easy to use content editing functions. From what I remember, there was a smaller learning curve and the metaphor they used for content mimicked a normal static website with files and folders. The other big difference I noticed was that most of the modules have to be paid for. Not sure if that means they would be of higher quality but something else to consider.
I'm also interested in some perspectives from Concrete5 users.
Concrete5 hands down is the best CMS I have used. I'll second what Chad says about clients picking up on C5 in no time at all. When I demo Concrete5 to potential clients that first thing they usually say is "I can do that." Users also love that amount of functionality that comes rigth out of the box and I like that fact that most of the code that I have worked with in my experience has been pretty solid.
As CTO of concrete5 I'm a little bit biased, but I can tell you that concrete5 does offer a lot of extendability, and we try to do so in a way that scales the learning curve along with your knowledge of the system.
For example, the CMS tools are simple to understand right out of the gate. You can build sites with no customization that clients can easily edit. Then, when you need a bit more, you can go to our marketplace to download free or commercial add-ons that extend the functionality of your site. Once that isn't enough, it's easy to create custom block types which present small, encapsulated bits of presentational content on your site, and let your clients use the CMS to place new instances of them. If you need more than just bits of content, you can use concrete5's custom model-view-controller functionality to start working with full pages and external scripts. From there you can start diving into the framework itself, including our concept of events (similar to hooks in Drupal/Wordpress), helpers, attributes, and libraries, and start working with our file manager, user manager, permissions and interface at a low level. You don't need to know any of that stuff to get started, however, which is what we think makes concrete5 so compelling.
And, as Chad mentioned, when you get the stuck, the community is one of the best and most responsive out there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I talked to a few friends who say that Drupal is amazing, and it is a way better than Joomla. What are the major differences/advantages?
The general consensus is that programmers prefer Drupal whereas mere mortals prefer Joomla. Joomla is praised for having a simpler user interface. (I personally don't agree with that; I think Joomla's UI is pretty painful to use. But then again, I'm looking at it with a programmer's eye.) Drupal, on the other hand, is praised for its high level of extensibility, along with its large library of high-quality (more or less) plug-ins that add features ("modules" in Drupal lingo) and many of which are extensible themselves.
Start using Joomla today, and you'll probably end up with a decent but not quite perfect web site tonight. Start using Drupal today, and you'll be able to build exactly the web site you're wishing for - once you've put the time in.
If you're considering parlaying your skills into a paid job one day, you should definitely side with Drupal.
The community around drupal - theres a module to do just about everything. Sometimes, theres more than one way to do something too.
If you want to change almost anything, from presentation (themes) to function (hooks), its possible. However, its not MVC and it does take a lot of getting used to.
With Views + CCK + Panels Module, you rarely need to touch code to create a wide variety of pages.
Finally, Drupal's User and Roles system is much more flexible.
The API. Every form and pretty much every bit of functionality can be modified via a module that hooks into the API, without having touch core code. This makes upgrades much easier, as your customisations aren't overwritten.
The code it outputs by default is much nicer, as well.
Under the hood, Joomla runs on mostly an OO architecture, whereas Drupal is almost entirely procedural with OO paradigms. Joomla has no form builder (that I am aware of), so you are forced to hand-code entire blocks of html for the form, whereas, with Drupal, you create forms as structured arrays. In Joomla, creating administrative features and front end featured requires that you place files in both administrative directories and in front end directories or create an install file to correctly partition things for you. In Drupal, everything pertaining to a particular module is contained in 1 directory, and you control access and url structure.
In general, Joomla's admin GUI is considered prettier and more user-friendly than Drupal's, but Joomla is, in my opinion, a less intuitive system at the programming level and makes certain tasks more difficult than necessary. 2 areas where Drupal truly outshines Joomla in my opinion is in the ability to create various content types - with various fields - on the fly to easily segment data, and the ability to create pretty seo-friendly urls with path or, even better, with pathauto.
Bottom Line: Joomla tends to look pretty from an administration perspective, but Drupal tends to outperform Joomla and be a more easily customizable system to achieve many of the things you really want out of a CMS.
Starting off, Joomla is fun and easy, from both an administrative and user view, but once the site needs to be customised (naturally), it becomes a pain.
In my opinion, Drupal is opposite. It has a steep learning curve (the pain part), but becomes easier not harder over time. This is from both the admin and user part.
For what it's worth Joomla before 1.5 was pretty ugly, and the API included a lot of very specific calls related to older Mambo code. The most recent version, and all future versions are built ontop of a very powerful OO framework, so if you haven't looked at it recently, do now.
Drupal shines with these two modules.
CCK: Adds custom fields to nodes
Views: Controls how lists of content are presented; it is essentially a smart query builder
What I like about Drupal is the plugin model: you have your core of drupal, and you can customize it however you want it by creating your own seperate template directory and modules (the plugins).
For a complete technical overview you can also tick Drupal and Joomla in http://www.cmsmatrix.org/matrix/cms-matrix