I'm using jQuery, ASP.NET, SQL Server, and the other usual suspects to design a company CRM. After they put in contact info, notes, dates, places and so forth they have to be able to select many different people to be "CC'ed." A group of people will be required to be one either "CC'ed" or "ToDo." The rest of the people can be nothing or "CC" or "ToDo." Currently we have it set up as a huge databind to templates with radio buttons for each option. Looks like shit. Anyone have any suggestions? I'd like to use a template with a datasource and have a good way to retrieve their answers and use them.
I'm leaning jQuery direction but like I said I'll need there to be up to 3 possible options for the people. This is going to be all opinion so I'm just looking for options.
Just to re-clarify, this concept is similar to email but I don't want them to have to type anything in as it is a set group of names that they're allowed to select from.
Looking for quick simple and pretty. somewhere in the range of 120 names.
If you intend to look down the jQuery route, I suggest that this widget could possibly help you out (even if only for inspiration sakes). http://quasipartikel.at/multiselect/
I'm struggling to "visualize" your form for terms of "real-estate expendature" etc.
Not directly what you are looking for, but this plugin may help
http://devgrow.com/slidernav-jquery-plugin/
Typing with intellisense. Sorry - any graphical thing will look overloaded.
Or: A table with filter options on top (again, typing). THere simply is no other way.
What I would most likely do to achieve this is implement the auto filter pattern that you type in a text box a few letters of the name and then it would filter down all of the overall results to those containing that pattern. Then have a select all button that will let you check all of them, and then the user can manually uncheck a few instead of having to check all.
The other thing to do would be to offer some type of categorization of the data so that they could filter by category that would put people in probable groups that would want all them all together. Like IT, HR, Executive or something similar.
Related
Let's say I'm creating some app documentation. In creating a content type for functions, I have a text field for name, a box for a general description, and a couple other basic things. Now I need something for storing arguments to the function. Ideally, I'd like to input these as key-value pairs, or just two related fields, which can then be repeated as many times as needed for the given function. But I can't find any way to accomplish this.
The closest I've gotten is an abandonded field multigroup module that says to wait for CCK3, which hasn't even produced an alpha yet as far as I can tell and whose project page makes no obvious mention of this multi-group functionality. I also checked the CCK issue queue and don't think I saw it in there, either.
Is there a current viable way of doing this I'm not seeing? Viable includes "you're thinking of this the wrong way and do X instead." I've considered using a "Long text and summary" field, but that smells hackish and I don't know if I'd be setting myself up for side-effects. I'm new to Drupal.
There is the http://drupal.org/project/field_collection module but it's not yet ready. Right now you would need to implement your entity alas to do this :( not easy.
Not sure how well it would work, because it currently does a bit more (eg, forces to group pairs into categories and the keys need to be predefined) but you might want to have a look at http://drupal.org/project/properties.
You could create a these key-value fields on their own: create 2 regular fields that that can be added as often as needed.
So you have a x fields for the keys and x for the values. If this is only for you or other people it might work OK but usability wise, it's very ugly.
If you need to extract the fields from the function, to display it properly in a page template, you should propably use a different approach. Write the function with its arguemnts in a CCK field and in the template extract them as needed. The arguments are always (depending on language) in () and the different arguments are seperated by , so splitting them would by pretty easy.
I am returning my views in the style draggableviews. At the bottom you have a save order. This obviously must set the CCK field I have for weight. Would it be possible to update over columns as well? Ideally you would be able to edit the columns returned either by free text or drop downs.
By the sounds of it I think I may need to code something myself.
By the sounds of it, you will need to code something. Luckily, the DraggableViews module is there as an example.
You might also want to look into Views Bulk Operations, the 10,000 pound Gorilla in the World of My-Views-Change-Things.
If you want the draggableviews drag-action to directly set multiple fields, it sounds like you need to visit it's issue queue, post a request, and be prepared to offer a patch. It sounds to me like what you need is a hook in draggableviews that allows you to specify additional field and a callback function for how to update it in the course of dragging.
I'm in a situation where I think I need to create my own custom search module. What I'm trying to do is make a page with a list of all my nodes in the node type - let's call it 'Beer'. So I want to be able to filter through the beers in a fashion similar to the one you find on the Apple Trailers page ( http://trailers.apple.com/ ).
I tried using Views 2 but ran it to a few problems:
I can't make the filter links like in the top of the trailers page (exclusive, just HD etc.)
The search function will only search one field (Exposed field "Beer title" but I also want it to search for manufacturer and other things.
I'm aware of a couple of solutions:
I could fix the last problem by using the Computed Field Module where I could combine the fields I want to search through. I just don't see this as a very elegant solution.
I could make my own module and create my own database queries where I apply the relevant filters (I just don't know how).
I could somehow use my already installed Solr module.
So the first solution - the easiest I guess but also kind of bad with duplicate content in my database.
The second solution - the best (maybe) - problem: I'm too dumb.
The third solution - Solr seems pretty cool but would I be able to present my beer nodes with just the title and a picture?
So I guess my question is. Which one of the three would you use? Or what other solutions could I potentially use (I'm confident there are things I haven't thought of :))?
Sounds like this could be a good use for Taxonomy not different node types. Also, Have you considered http://drupal.org/project/quicktabs ?
You could set up each "filter" as a tab that passes an argument down to a view. Then don't expose any views filters to the user.
I'm building a form and I wonder if there is a significant advantage in showing values in a more human readable format; e.g:
index.php?user=ted&location=newyork
Rather than:
index.php?user=23423&location=34645
On the one hand, having the query string a little more readable allows the user and search engines to better understand where they are, but this also creates a little more work on the server side, as I'll have to track down the associated rows through something other than their unique id.
For example, first find what the id of 'newyork' is before being able to work on other rows that require the location_id. I always prefer to give the db as little work as possible.
Edit: decided to go with readability. I figure I can always use the mysql query cache to speed things up if necessary.
Use human readable values when you can. Just be sure to sanitise the input.
Edit: Yes, this can and should still be done for SEO purposes (if its worth it to you) if you have lots of choices. Even if the user has lots of choices, you should know what they are (or what the limits are) so that you can properly sanitise the input. For instance, if they are choosing states, you can know all 50. If they are just making up their own text, make sure on your end that its only text.
A good rule of thumb is to store data as id's and display it as human readable text etc.
Depends on your goals.
If you are talking about something like a blog where you want everyone to see everthing (and find it easily), then the human/search engine readable format is a no brainer.
If these pages are locked behind a login then it doesn't much matter. You can do what is easier on the database.
For most internet apps, I'd err to the side of readability since that will help with search engines as well.
You shouldn't worry about the efficiency for any typically sized application on any reasonable database engine. Write your app for users, not for query optimizers. QO's can more easily take care of themselves. Deal with optimization in the unlikely event you start seeing a problem.
I am going to come from a different direction. In my opinion a URL should be readable if want the user to be able to use the URL to change their parameters by editing the URL instead of using the UI. An example would be https://www.coolreportingapp.com/accountReport.jsp?account=ABC&month=200911 . In this example, the user can "easily" change the account or month they looking at without messing with the UI. This of course means you need to validate the URL params each and every time, which you should do anyway. If you don't want the user to alter the URL params, you need to obfuscate and hash values and use the hash to verify they haven't.
Seriously, IMHO, in your example, none is more readable than the other. Do normal users know that "&" is a separator from "variables" in "user=ted&location=newyork&"? Do they need to know that exists something like a variable? Having this in mind, what's the difference in showing numbers or words?
If you really want readable urls you should build SEO Friendly urls (human readable). Remember that even a "dashes vs underscores" simple question matters in the end.
I am building a real estate website. I have a table for properties (i.e. "houses"), a table for pictures, a table for features, etc. So each property's data comes from three, not only one table.
I need to provide a function that retrieves requested property data depending on a search criteria, for example:
property of the week
featured properties
properties on offer
the simple search
I have multiple drop-down lists for selecting country, region, area, bedrooms, price range, type, etc.
I already built many functions each dealing with one of the above cases, but I was wondering, if there was any other way of building one flexible mechanism that will retrieves whatever you want in a smart way, I mean one function that works for all cases?
I know my question is kind of vague and too broad, but bear with me please.
Thanks in advance.
PS: I am using ASP.NET 3.5, VB.NET, Visual Web Developer 2008 Express, SQL Server 2005 Express
I think you're looking to build an Advanced Search functionality that integrates with the default/simple search provided.
Why not build a single stored procedure to encapsulate all possible types of searches by specifying default values of parameters that are not passed.
In this manner, the simple search would be using all parameter defaults. Whenever any criteria is provided to narrow the search, the passed parameter value will be used by the Stored Procedure.
Is Lucene an option? Lucene.net is a great way to provide a quick and flexible search engine to your site.
When you use Lucene you also many other advantages, like fuzzy search etc...
http://www.codeproject.com/KB/library/IntroducingLucene.aspx
The question is twofold:
Can you logically unite the search for "properties of the week" and the search for "properties in this specific region, costing 100,000 or less" into a single database search?
Does it buy you anything to think of/create something that does 1.)? (Especially when you already have something that works.)
If you would answer both questions with "Yes", then I'd say you must extend the simple search. I suppose you already have a flag for each of your special cases ("property of the week", "property on offer", etc). Just add support for these flags to your simple search function.
Provide reasonable defaults for the search criteria and you can use simple search for all the cases you described.