I would like to add a comments section to our postings. Our websites are based on Java and Wicket framework. I searched for some ideas to realize a comments system but couldn't find any kind of approriate solution.
Maybe someone knows about a solution. Maybe there are other possiblities.
Tanks for answering, but this question is outdated!
Well you can easily write this on your own. just a view database tables for holding and managing the thread and its comments. Let the editing be done through tinymce as said an display the content as you whish. There are a view Repeaters to list a Collection of any kind holding some DAOs to iterate. For what kind of speacial features exactly are you looking for, that might be to difficult to develop them on your own? If you want to keep it simple, this would be all you need.
Related
We've been asked to create a form that is more of a long-form questionnaire, eventually bringing people to the information they need.
Our institution uses Plone and would like to find an existing solution, ideally integrated with Plone.
Is there a Plone plugin that can accomplish this or should we look elsewhere?
Have you looked at PlonFormGen and its documentation? It allows all kind of adjustments, so might fit your use case.
If it's multi-page surveys you're after, PloneSurvey might fit the bill.
If it's a glorified navigational instrument, you might want to rethink and offer eea.facetednavigation‎ instead
I need to develop a client application for a site that host and show images.
The client should shows all new images and take a picture and send to website.
I'm a newbie to iOS programming so this question:
In an application alike this, there's the need to create a Model? I ask this question because I think I can do anything with Controllers but maybe I'm wrong.
While there is never a "need" to create a model, it's good form to do so, and it'll likely save you many headaches down the road. Ultimately, you're going to need to deal with images and websites and how they interact with each other and whatnot, so you might as well do it in models from the outset.
I'm as guilty as anyone for wanting to see immediate results and hack together something quickly, but I always regret it later on, and have to spend more time than I'd expected refactoring it into something usable.
The MVC pattern as used in Mac OS and iOS applications isn't something best explained in an answer box but here's a link to some simple documentation about the roles of Models, Views and Controllers
Some good basic introductions to start with, which also have relevant links to the next stage of documentation are:
Cocoa Core Competencies
Cocoa Application Competencies for iOS
Read these excellent articles first. You'll learn better and faster if you do some basic reading.
I know this topic was discusses a couple of times, but none of them represents the ultimate solution for me.
Situation
I'm designing a relational mysql database which later should hold multilingual content. You know this from the Wikipedia or Microsoft Tech Support Pages. The contents should be the same for every language. e.g If translations are missing the site offers you the same content automatically translated or in the languages which the information is available in. If some values are not set, it should fallback to the second or default browser language or translate it e.g. through google. Development environment is Zend.
My ideas so far are for Solving the Problem:
Two Primary Keys: (ID, Language)
Advantage: Easy Database Access through database abstraction layers.
Problem: Foreign Keys, Relations ships, Fallbacks
Columns with language suffix:
Advantage: DB Performance, No relational Problems.
Problem: Database abstraction layers cannot handle this?
Has any concept proven itself or is preferable over the other? Has anyone already created something like this and can share his experience with me? Does a modified Zend DB Controller exist for this situation? How do you link this information to a form?
Thank you for your help, hints and suggestions!
Kind regards,
Manuel
The second option would be not maintainable (this should be added on the minuses side). To actually add another language you'll need to modify table and abstraction layers. Sounds like a nightmare.
The first option seems much more promising but unfortunately there is a lot to do to make it work. However, from my experience this is rather typical solution, so I would not reinvent the wheel.
What I have to add is, language fallback should be done on the Zend side, database would miss some information. You may think of some kind of index table to hold information such as unique id of the contents and available languages. If you need to serve something, you would read such record, compare it against of Accept Languages and ask database again for valid contents (using the most suitable language). The only problem is, you would need to create such an index table somehow (the best way I see would be trigger on inserting contents to your content table).
A lot of work but the problem is not too easy.
I am working on the exact same problem right now.
Somehow it does not make sense to me to add everything into the same database. Lets say I want to go to the extreme and support some 50 languages this would just bloat my DB. So, I tend to keep my main DB in my main language and then introduce some Zend_Translate concept into it. Zend_Translate should give you the fallback solution you are looking for. While the main navigation and core design is not much of a problem for my web site my biggest concern right now is how to store all the main content and how to translate because these elements contain HTML among other things. For the main content I will probably use some alternate approach and use a separate DB with tables for each language.
My plattform will be a community driven database. So I actually gonna rely on humans translating it. You have to store the information anyways, so my first concern is not the database size or performance, but easy usability. So far my idea is to implement some structure as described above, not yet sure if i'll do it in doctrine or not.
Language decision:
Start, application gets users preset language, secondary language, english mother-tong of the article. Fetching the article from the database I will check the following for every column: 1. is the primary language available? 2. Is the secondary language available? 3. If neither of them, display article in mother-tong or english and offer the user to translate it with suggestions from the google translate api. I guess it's gonna be quite a bit of coating and manipulating controllers or building a business model doing this.
#tawfekov is something like this or similar easily realizable with doctrine?
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 6 years ago.
Improve this question
What is your method of "mapping out" an idea before creating it?
Say I wanted to take on a big project, for example at the scale of a site like Facebook or MySpace. What planning/design steps should I take before I start the actual work?
For example, should I map everything out page by page (their functionalities, data, etc.)?
For a large project first think of a one-liner to description of your site (try to not use any buzzwords here). Next think of three design maxims (rules your design Should never conflict with). Then draw a few views and think up a few user cases (1 day) then work in code for 2 weeks (this will be a throw away prototype so just work as fast as you can forget about bugs and details, don't worry about code smells or design patterns, just make as much as you can), then revaluate all the steps above and throw away your two week prototype, and begin your project in a serious manner applying solid engineering and design. After a month has gone by evaluate your(team) moral and get feedback. If it all seems to be going ok, continue, you got a long ride ahead, otherwise just give up, do a postmortem, and start over with new goals.
I always start with the user interface design. I figure out what the user should be able to do and what controls I will give them to do it. Once I get that laid out in a way I like it, then I start with the code "wiring".
Make a list of all the features that site have.
Make a list of nice to have features.
Make a list of the weakness of the site.
Order that list and prioritize the items that will be built first.
Identify what will be possible to do and what is not.
Meet with your customer and present these results.
Usually I do a mindmap of
problem I am trying to solve,
translated into exact requirements,
then mapping that to user workflows.
The cross linking features of mindmapping softwares make it lot easy. Since mindmapping is 'kind of freeform', I end up concentrating on the 'task' rather than 'representation' (e.g which type of UML diagram should I use to represent this) ?
Once initial ideas are clear then I can work on project plan, spec/design documents using UML for more low level details. This approach usually works well for me.
To see if it works for you or not, you can use FreeMind (opensource mindmaping software, good but currently limited functionality). Then You can try Mindmanager or iMindmap for mindmaping. Both integrate well with other Office products.
Usually I start out by grabbing my scratchbook and just start writing down what I want as in terms of features, this should be quite detailed. And can be quite messy with every thing scrambled together, if so, when you're done make an 'official version' of you're ideas on paper (REAL pen and paper works best for this in my opinion).
Then I start making some scetches of how the pages would look like, what information it must contain and translate that to a global database design. Then work that global design to a more advanced level where all pages come together, with relations between tables and stuff.
After that I build up the most important pages on a code framework (I always make use of a framework, if you don't then forget the framework part), and by 'most important pages' I mean in for example a blog that would be the posts. After that build the not-so-important pages, in case of a blog that could be an archive of posts.
If you have that done, put the code together with a design, or do that while coding if you do not seperate code from HTML/CSS/JS.
Oh and yes, do NOT expand your first idea along the way. Just write that down and implement that afterwards. So if, in case of the blog again, you think half way you want Youtube tags in you're BB-code, write it down. Add that later, offcourse before you're initial site releases.
That's my workflow, at least a basic basic, basic description of it.
Start with "paper prototypes", i. e. take a pencil and sketch each page very roughly. This lets you start from the user perspective, which I think is a good idea.
You can then use the sketches for a first hallway usability test and later as the basis for "wireframes" you would give a web designer to work from.
If you've gone through the complete site once, you probably have a good idea of what the backend should be able to do. You can now use your page sketches and compile a list of the actions a user can trigger by clicking on things. This is the raw material for designing the server-side API that the frontend can call.
Using the calls that need to be served, you can design the backend: What functionalities group nicely, what data needs to be fetched, what do you need to store between page calls (== Session variables) etc.
In this process, I have fared quite well by postponing technology decisions (frameworks, protocols etc.) and even class structure etc., until I've gone through the whole thing once in terms of "what things should do what to what other things" (I guess there's a better term).
I think I would start with an open-source SNS solution that comes close to what you need and then figure out how to add use-specific plug-ins, modules, and themes that achieve your purposes. There are a lot of em out there. Building from scratch is going to take a lot more effort and planning. Most SNS functionality is not worth re-inventing. Focus on what will make your site unique and build upward toward that.
I'm a fairly visual person when it comes to designing software so I sketch out dataflows, class hierarchies, UI and flow charts on whiteboards and paper first.
Butcher paper and colored pens can be particularly fun to use as it's 3 feet wide and comes in 100 foot rolls. When you've got a design that's satisfying or sufficiently complete, tear it off the roll and pin to the wall. Update as necessary.
That technique has worked for some large refactors as well as new projects.
You could start with something very simple and then add features a little at a time. You may reach a point where you want to start over, but the groundwork you did will be beneficial. Or you can try to do the whole thing at once, in which case you'll need the advice already given in the other replies.
One more idea: Specify those features you are not going to include, and other restrictions. These are called constraints, and are as important as the rest of the plan, as it gives you boundaries so you know when you're done planning!
If you work for the same company as this person, start by getting everything in writing so you aren't the one to take the fall when the inevitable happens...
I need to create a internal website and can't figure out if we should be writing our own, or using an existing framework.
Most of the website will essentially be a front end to a database. We need to have a number of people enter data into forms. We then want to be able to show different views of all this data -- including running small queries (e.g. how many resources do we have with attribute 'X'). As is usually the case with this, we will want to tweak the UI on a regular basis.
There actual data design is not a simple 1:1 mapping of resource to entry. For example, we might track several attributes for one item as the "base set of data" for that item. Then we could have several additional sets of data.
Imagine a recipe application. You might have a recipse for a starter. This could then be referenced by several other recipes that need that same information.
I feel like this is best suited for a general framework (Ruby on Rails, Django, etc), but I wonder if it might not be good for a "traditional" CMS platform like Drupal? I specifically mention Drupal since the people that would develop this have the most knowledge using php and MySql.
I usually lean towards wanting to use an existing platform, but am interested in other people's thoughts. To give you an idea of scope, I would imagine if we wrote this from scratch we are probably talking about 3-5 weeks of development.
Would you recommend writing our own, or using an existing framework? If you would suggest using something that exists what would you recommend?
Would you consider this to be best suited for a straight framework or a straight CMS?
Thanks!
It's possible that Drupal will be a good solution for you, though you'll probably need a few key additional modules like the "Content Creation Kit" (CCK) and "Views".
Unlike other web CMS systems (WordPress, Exponent, phpNuke), Drupal treats your entries as a "pool" of content, from which you pull various subsets for different areas of your site.
There is a lot of documentation for Drupal (almost too much), the biggest problem is finding the piece that's relevant to what you're trying to achieve. Diving on to one of the interactive IRC channels can be a good idea, as the community is quite helpful and is almost always willing to give you a pointer in the right direction.
The power, flexiblity and capability of Drupal is both its biggest strength and weakness - I know it took me a bit of effort to get my head around key concepts, and I'm far from being a Drupal Expert.
One last comment: Having written my own CMS from scratch, which I abandoned in favour of Drupal, I'd suggest your 3-5 week estimate is likely on the light side.
Stay away from Drupal for any site that requires customized functionality. I recently used Drupal for a website at work, and it was VERY difficult to figure out how to get it to do what I wanted it to do. There is a lot of documentation out there, but all of it is unhelpful -- it answers very specific questions about specific issues but does not provide any context as to how you would approach building the site as a whole. If you're a programmer, using a more general framework will probably work better, as CMS's are designed for a specific kind of site, and if you want your site to have non-standard functionality you are going to be fighting the system instead of working with it. If your developers are most experienced in PHP, try one of the PHP frameworks that mimics the architecture of Rails -- e.g. cakePHP or CodeIgniter.
CMSes usually make sense when you have a broad and potentially expanding array of different content types and modes you need to handle. Drupal has literally dozens. Given than you mentioned RoR, it sounds like what you need is more of a MVC style framework. Maybe similar to the sort of thing stackoverflow was built with. .NET an issue for you?
If you are really limited to 3-5 weeks, however, I think a Rails-based strategy makes sense so go with RoR or CodeIgniter
If Drupal can do what you need easily I would say go with Drupal. I don't know much about Drupal though.
Otherwise, what you describe sounds like a data driven web app or more like a reporting app. It sounds like you might have some very specific needs or that users might want very specific needs in the future. That is something hard to get from premade software since you have no idea what users are going to request. Since I'm a programmer I would probably want to build it myself.
Funny you should ask... I just came across this in SD Time's Linkpalooza this afternoon:
Ten free powerful content management systems…
There are at least 4 more mentioned in the comments to this post.
It seems to make little sense to develop a new one with so many from which to choose!
BTW, this is neither a recommendation nor endorsement of any particular CMS.
Treat Drupal as a framework. Core modules + CCK + Views is a good start to build on.
If you're doing something that you might want to expose to other applications, consider the Services module. A lot of interesting things have been done with flex frontends connected to drupal running services with amfphp.