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 11 years ago.
Improve this question
I am building a web site for baby names. Users can submit a name, meaning and some tags, and moderators can edit/approve it. Very small amount of data is used for each entry/post.
Looking for some kind of framework that supports the following features or I can easily extend it,
Unicode support
I have large number of names, I should be able to import them into my website by code.
User roles and permision
Some kind of report options. For example, Display list of names that starts with some alphabet or list of names for a #tag
Full text search
oAuth/OpenID
Are there any frameworks like Orchard, Umbraco I can leverage or would I be better off writing a new ASP.NET MVC application?
If I were you I'd surely stick to some available CMS platforms (Orchard or Umbraco) instead of writing from scratch and reinventing the wheel.
From my experience with Orchard I can say that setting up a website as you described would be pretty easy and painless with this platform.
Features like those you mention are already available in Orchard, but I guess (as with just about every CMS) this will surely need a little customization to suit your particular need. All the custom functionality could be easily wrapped in a single, custom content part. How to do that is very well described in the Orchard documentation.
Of course.
Without a problem. You have three options: import directly into Orchard DB (into the corresponding tables), import using Orchard Import/Export functionality (which would involve exporting the data to XML recipe format first) or just use the current data source without the need of importing. There was a question on SO a while ago of getting data from a custom WebService. The solution provided perfectly fits here, so please take a look.
Out of the box - described here and here.
I don't know if you meant the backend (admin) view or in the frontend? Tagging and displaying tagged items is available oob. More complex, custom reporting would involve some custom coding (writing a custom content part).
Available and described here.
Sure! It's available via very nice OAuth Module, written by Nick Mayne. It allows you to bind Orchard accounts with OAuth providers.
I don't have much experience with Umbraco though, so I can't give you any direct help, but I guess it'd be nearly as easy to built your website using it.
Personally, I prefer Orchard for its flexibility, extensibility and code freshness. But the choice is a matter of your personal feeling and preferences. From what I've seen they have very similar functionality, although differ much under-the-hood.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
This is not an opinion based question but rather a technical limits comparison one.
From the various comparison charts about the two CMS I couldn't really find any technical difference between the two platforms. Being a long time WordPress developer I find the supplied arguments about Typo3 technical pros exist somehow in WordPress; Everything you could achieve in one can be achieved in the other as well (plugins & extensions).
Let's take for example the latest versions of both two CMS's, what does Typo3 can do that WordPress can't even with its plugins/extensions?
UPDATE
Please instead of down voting the question, provide at least 1 reason for your vote.
Yes it is opinion base question, so there's my opinion (not an answer).
TYPO3 from the very beginning was considered as a Content Management Framework (that means CMS with possibilities of further custom development) while WordPress was just a blog. Of course with time things changed, as more and more people tried use the WP to doing more serious things. Anyway in WP the main disadvantage till now is "blog way of thinking" - in TYPO3 you have open structure - building services on the unlimited nested tree, while WordPress (probably) is still basing on the primitive structures, category/post/site (note, I'm not familiar with WP, so maybe there are some workarounds for this now).
You should install TYPO3 and compare the way how you put the content on the pages, how you can control the access for both FE and BE users and also such things like versioning workflow. with all my sympathy to WP I'm almost sure that's not so easy to do such things in it.
Also starting extensions with Extension Builder is just matter of minutes, so it allows you to deliver solutions to your clients exactly in the way as they want.
Conclusion, from my POV I wouldn't choose WordPress for most of my clients (car producers, publishing houses, building developers) on the other hand last time when I was asked by cellogue of mine for creating typical blog with TYPO3 I did it ... with WordPress and he's satisfied with it, me too.
As my partner used to say: "CMS is just a hammer, it depends on requirements which size you should choose"
As you write, the technical pros exist somehow in WordPress.
I personally think a major advantage of TYPO3 is the extension framework extbase and the template rendering engine fluid.
Developing (and maintaining) larger extensions becomes a lot easier since their introduction as well as an overall cleaner, fully object oriented code base.
3rd party extension written in that technology are easier to adapt/customize than some extensions in Wordpress which sometimes mix procedural with object oriented style.
Webpages with multiple languages are easier to handle in TYPO3 (e.g. content fallback), which makes it more interesting for bigger projects.
Take a look at the TYPO3 showcases and the Wordpress showcases, to me it looks like Wordpress is primarily used for subsites (like blogs, landingpages etc.) whereas TYPO3 is used more for corporate sites (which probably have a longer life cycle).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm relatively new to Drupal, but not CMS's in general. I'm creating a site for a client. The most important part is creating a fairly complex form in which users input various types of data to be stored in the database. I had assumed the best method for doing this was to create a custom module. Is this the case, and if so can someone direct me to documentation or a tutorial on the best way to create a module of this nature? If not, I'm open to suggestion for the best way to create this kind of form even if it is hardcoding the content.
Drupal.org contains detailed tutorials on how to create modules, see for example this one.
The Drupal Form API will be your friend to handle easy data capture: How to use the Form API.
Depending on your data capture needs, the Webform module may already do what you want.
In drupal there is a Form API to do this, a very good working example is used in the documentation at drupal community, here are the links for that:
Drupal 7 Form API introduction
Form API reference for Drupal 7
And one more thing Never go for hard coding things try taking the advantage of all available API's.
You haven't detailed who the users are that will be inputting data into the form, the complexity of the form or what you will do with the data so I'd like to present you with some other options.
Custom Content Type
You can create a custom Content Type and assign appropriate permissions so that users can fill in the content creation form and it can be saved in the database as a Node entity. The Node is a core Drupal entity and therefore already has many built in capabilities for sorting and displaying using the Views module and permissioning, etc.
But the users filling in the "forms" (ie. creating Nodes) have to be registered Drupal users.
Webforms Module
Drupal has a Webforms module which will allow you to create a form without having to do any custom coding. The module looks after creating database tables and already has a lot of built-in functionality.
Refer to the other answers if you find that it's still most appropriate to create your own module.
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 2 years ago.
Improve this question
I believe that one needs to buy a license(?) to use devexpress. I'm currently implementing a gridview and want the sorting arrows to appear in column headers. I know that devexpress grids have that feature and I believe many more? Could anyone point out any specific reason why someone would pay for using a devexpress grid, or I guess the devexpress suite comes with a lot more than just grids?
Could anyone point out any specific reason why someone would pay for using a devexpress grid, or I guess the devexpress suite comes with a
lot more than just grids?
Here is your reason of paying for the third party controls, In Short features give preference to use these rather than the standard controls.
it’s unlikely for the client to have a specific request about some user interface component that can’t be satisfied with either default controls or 3rd party controls. Many of the convenience aspects like detailed view, sorting, auto completion, filtering, and changing perspective have already been solved by the 3rd party companies over the several versions of the controls.
When in need for some UI functionality, it’s better to search the companies’ websites for something suitable, instead of trying to develop from scratch. It will also certainly be cheaper than going over the document, develop, debug, test, and deploy cycle countless times.
By using 3rd party controls it’s easier to keep focus on the actual business functionality for your project, to spend time developing visible features for the application, than to work on solving the many background technical difficulties associated with developing every functional request.
On the other hand, if you reach the conclusion that the control would require some serious modifications in order to suit your needs, it’s probably better to do the entire development in house, eventually based on the simple default controls that come with the .NET Framework.
For example, I do use devexpress controls, on which project i am
working they specially require a developer with knowledge of
DevExpress control, because that will reduce the development time(
Project completion Time also) rather than using the standard control.
The Specific requirement make them to pay for the controls as those
guys commented in this SO thread.
Check these for feature comparison - Standard GridView vs DevExpress GridView. I like it's client side functionality..
Here's a reason. Because they want sorting arrows in column headers. Also, any of hundreds of other features these products provide that the default grid does not.
The point is, the extra features ARE the specific reason.
Not only does it take care of operations such as sorting and search. It is actually very useful in helping you populate data from your database easily by quickly mapping your fields to IQueryables (If you are using C# and not DevExtreme). If you're using the grid on many pages in your platform, you can easily configure all these grids from one single point (Themes, Functionality, Configuration, etc...). It also provides additional security measures to prevent certain injection attacks. Finally, it is always updated with new features and improvements with constant releases. One really important thing too is that the DevExpress help center and forums are very rich and you will find an answer for almost any question or issue you come across. So using the DevExpress component will bring scalability and increase reliability with time for your platform.
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 9 years ago.
Improve this question
I am looking for a library to convert HTML to PDF, including styles. I would prefer it be able to accept a URL as an option, but if required, HTML can be passed in as a stream/byte array with all styles in a single file/buffer. I am using C# / ASP.Net 3.5. I have complete control of the server machine ( I can run as a service, etc... ) however, I cannot require the user to be logged in, so no application level or print driver type solutions please.
I know there exist free solutions like PDFSharp, but these still require you to format your output properly. I want the library to generate almost identical output to the source input, which this library doesn't provide ( or at least, I believe it doesn't, correct me if I am wrong ).
I also know there are a number of commercial products available. Some of them are a few thousand dollars, which is beyond my current budget for this feature. There is one library ABCPDF which seems to do exactly what I want to do, for a price I can afford to pay. That said, the lack of professionalism/polish on their website has me a bit wary.
If you have experience with ABCpdf, or can recommend a similar library ( price feature wise ), I would greatly appreciate it.
EDIT: Thanks all for the answers. Sounds like abcPDF or aspPDF are the way to go, and both are within budget.
I use and highly recommend ABCPDF for what you need. I use it to pdf complicated html reports (nested tables & lots of css, & charts). It works fantastic pointing it to a url.
As a bonus it supports the page-break-inside: avoid css.
Back when I wrote classic asp, I used their ABCUpload product, which is also fantastic.
Not a recommendation but....
Stay away from iTextSharp for HTML -> PDF. Its the only "approved" PDF gen lib my current employer allows. We've spend endless hours trying to convert HTML to PDF...its just not what its good for. iTextSharp is great for PDF versions of forms
I have used ABCPDF in the past and it is a very good product for the price.
I have had to use their support as well and they were very quick at dealing with an extremely obscure issue. Good communication and turn around time. I think it was 2 days from the time I put in a ticket to the time a solution was found and resolved.
They have also been very easy to work with with respect to licensing as we have had to buy older licenses that were no longer available (so that an existing product did not need to be retested).
Before settling on ABCPDF we tried 2 or 3 open source products but none had the flexibility or level of support we were happy with.
Here is a link to a thread that I commented on that was looking for a similar product:
Generate HTML To PDF Control for the .NET application
We use ExpertPDF's HtmlToPdf converter, which is pretty nice. Our company has an old license, but many new features have been added. It is pretty straightforward using CSS.
http://www.html-to-pdf.net/
ASPPDF supports HTML to PDF including stylesheets.
http://www.asppdf.com/index.html
But, commercial.
I was using aspPDF but from Persist Software, and it works very fine for my project.
It is very impressive, and it has support from a company developing asp components since the beggining of the ASP.
You can check very good live demos at: http://www.asppdf.com/livedemo.html
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