I'm using SQL Server Reporting Services 2008.
Per Microsoft, the following are the only tags that are supported.
Hyperlinks: <A href>
Fonts: <FONT>
Header, style and block elements: <H{n}>, <DIV>, <SPAN>,<P>, <DIV>, <LI>, <HN>
Text format: <B>, <I>, <U>, <S>
List handling: <OL>, <UL>, <LI>
My problem is that when rendering reports, style attributes are ignored. Most importantly for my problem, background color style is ignored. (I'd love support for other style tags, but this is really the big for me). I opened a support case with Microsoft, and they confirmed that this doesn't function in SQL Server 2012 either.
I've been reading about Custom Report Items - and it seems like SOMEONE must have handled this problem already, but I have now spent more time than I care to admit looking for solutions to this problem. Are there commercially available solutions to this problem? I can re-write reports using an additional reporting technology (Telerik more than likely), but I hate to spend the time and energy to do that when I've got a 98% workable solution already built using SSRS.
Just so everyone knows exactly what I'm talking about, when entering data into my database, I'm entering this data:
(I'm a new member, so I can't embed images - so I had to include as links:)
The Data I'm Entering : http://i.stack.imgur.com/xB5R4.jpg
The way SSRS displays image http://i.stack.imgur.com/UKM50.jpg
Finally, this is the way the information is being stored in the database:
<div><font style="BACKGROUND-COLOR:#FFFF00">highlighted yellow</font></div>
<div> </div>
<div><font color="#5C83B4">Blue Text, no highlight</font></div>
<div><font color="#5C83B4"> </font></div>
Does anyone have any suggestions? I can't be the first person to whom this has been a big deal for SSRS, but it seems like most people have been able to make do without this. Unfortunately, we're moving from automation of MS-Word to SSRS, so losing that important piece of functionality would be seen like a giant step back to our users.
Your question borders on asking for recommended libraries and opinions. Nonetheless, let me summarize the options and the way I see them:
Don't chop your text into divs, but use other SSRS toolbox items such as tablix cells and textboxes, and give those a background color.
Create your own component. Certainly possible, but quite a pain to get it working IMHO.
Choose a third party component. Stack Overflow isn't very good at (nor meant for) recommendations, but a quick search would render at least one result.
Switch to another reporting tool.
Drop the requirement. (Okay, you stated that's not possible for you, but others landing here may want to consider that option.)
Don't skip the final two options too quickly ;-)
Related
I am somewhat struggling with a project that I have set myself to do:
I am attempting to create a Web application for ServiceDesk work schedule. The app would show a schedule on a principle of week/month/year with the option to change view and enable users to see a spreadsheet like schedule for their daily assignments. A similar view as such, just maybe less detailed.
I am trying to build it in Oracle Apex. Now I have narrowed it down to 2 possibilities in terms of layout: either I use calendar, in which the layout would be slightly different and would basically have to show each task with details of who and what, or I go for Gantt chart and make it so that the left side shows names of the employees and the upper side shows time in days/months/years.
What I am struggling with is whether one or the other is the right way to go. I am trying not to make it too complicated for the administrator to make changes (at the moment, the work schedule is in excel spreadsheet, updated every month) as that would be counterproductive and could make it worse to use than excel. Also, the reason why I chose Apex is the fast that the company I work for actually uses apex in a lot of the projects and would be a bit easier to integrate with the rest of the systems already in play.
Any tips or guidelines to follow would be greatly appreciated!
Jervis,
Based on your comment:
Apex Calendar region is not appropriate here, as the ability to customize it is very limited. You couldn't even get it to show the 30 days shown in your mock-up.
I don't think Apex Charts would allow the formatting you're looking for either.
You need a grid region of some sort where you can arrange and style it. You can try an Apex Interactive Grid region. That doesn't include drag-n-drop functionality out of the box and I don't know of a free plug-in adds that functionality. That will probably do the basics of what you want
If you can pay for a commercial Apex framework, I'd recommend the FOEX Enterprise framework, which adds a ton of functionality and interactivity, including editable grids that you can drag-n-drop. It's not cheap (per-developer licensing) and there's a learning curve because it's a different way of doing Apex, but it's a very solid product and you can buy consulting time from them.
(I'm a FOEX customer, not an employee or a shill)
TL/DR: I have a game plan on how to do this below; however, I am wondering if my plan is going to prove to be too complicated, and what additional considerations I need to take into account before diving into building this project. Although I am not an experienced programmer, I am NOT asking for code; I am asking for feedback from experienced Word VBA programmers as to whether my entire idea/approach is one huge mistake.
I have a document "template" (not yet a template file type - I hope to create that as described below) for a report. The report is broken up into different sections:
Letter to the Client
Table of Contents
Section I
Title Page
Body
1.0
2.0
Section II
Title Page
Body
1.0
2.0
Appendix A
Title Page
Body
Appendix B
Title Page
Body
I want each major "metasection" (such as Letter, Section I, Section II, Appendices) to have different styling and formatting. This could be accomplished by having multiple styles for each metasection, e.g.:
Normal-Letter
Normal-SectionI
Normal-Appendices
Heading1-Letter
Heading1-SectionI
Heading1-Appendices
This would quickly become unmanageable.
In order to avoid users having to wade through a huge number of styles to find the correct one (and it is worth noting that if users of this report have to do this, they will likely not use styles AT ALL), it would be nice if I could have the same style name (e.g, Normal) be different depending on which section of the document it is found in. Or said another way, I would like for a document to have multiple style sets depending on the section.
The goals for the user experience are:
The user simply applies the Normal style, Heading1 style, etc, as necessary.
Registered section-specific style definitions are updated when styles are edited via the Modify Style dialog box, or other ways.
The styles are applied automatically and transparently when styles are changed, or when the document is opened, saved, or printed.
ALTERNATIVE: If automatic/transparent style application proves too difficult, execute the style-application routine with a simple command button.
My initial idea on how I might do this in VBA is:
Write VBA code (probably a class) such that there is a style registry of Normals and Heading1s, etc., for each document section.
Write a style-application subroutine which iterates through the registered document sections, selects all the parts with each registered style, and applies the section-specific style from the style registry (preserving any styling that deviates from the style definition).
Write a style-update subroutine that automatically and transparently updates the registered style definitions
The style-application subroutine executes any time styling is applied anywhere in one of the registered sections (so I'll need to tie into Events here).
The style-update subroutine executes any time a style definition in a registered section is changed (so here's another Event I'll need to monitor).
I previously asked a similar question about this topic on Superuser. The feedback I received has led me to believe that I can only accomplish the behavior I want using VBA, so I am now asking a follow-up question here on Stackoverflow.
My question is: am I making a mistake here? I have a feeling there is a better way to solve this problem (perhaps using VBA, perhaps not) than this.
Yes, in my opinion, you are making a mistake.
I have just recently finished a project where I have created a document template for a company. My experiences:
Users vary in knowledge level (obviously)
High level users don't like over-engineered files, because they can't use their own macros as they might conflict with the file's own macros, they can't use their doc properties or their own building blocks etc., as these likely won't be compatible with the macros (or at least they think they won't work, and fiddle around until they actually manage to break them)
low level users are intimidated by the automatisms, and keep avoiding them as long as they can (which means as long as their bosses don't order them to use the file), after which point they start hating the file and the work
Complex solutions like this one usually get abandoned after a few years. Eg. the original developer changes jobs, or moves to another department, and nobody understands the code enough to keep managing it (especially if it is not a well-documented, well-written code, which it won't be, as you are not an experienced VBA programmer).
The developer (you) will be inundated with (sometimes false) bug reports and questions and minor change requests, which gets really annoying after a few weeks (trust me on that :) ). They won't dare change even a font size without consulting you, and in the end, they will ask you to do it. Or, even worse, they try to change something, break it, and then tell you to fix your bug.
Your users would have to remember to use section brakes or other kinds of indicators to indicate the next section. This will seem too much for some, too complex, and if they accidentally remove a section indicator (which they inevitably will), all hell brakes lose, and worst of all:
Undo function will be disabled after each macro run. This, to most users, is a disaster. You don't do that to your users.
So I would say don't go down the macro route. Don't use Doc properties, that didn't work at the company I was working with. (Actually an IT company, with mostly high-level users :) ) The high-level users will create and use their own doc properties, for others, it is just a hassle. Bookmarks get constantly deleted, so no-go either.
My advice:
Use styles. Users will learn to use them quickly.
Get a decent document design. Having 4 different sets of title, heading and normal styles in one document is really unprofessional. Consistency is important, especially as this seems to be a letter to you clients. (Yes, I know, your company is different and your bosses are dumb and this is a special case and and and ... Just saying, talk to a designer, and get a professional look for your template.)
You can manage the Style gallery (Home tab, centre) drop down list on a template basis - so your template will load the used styles into the dropdown at the top, and remove everything else. This works really good, and even as much as 20 styles is manageable, if they are well-named.
Use building blocks: title pages, tables, pre-written and formatted Quick parts (legal mumbo-jumbo, company introduction, contacts, etc.), headers and footers...
And, if you want happy-happy and cooperative users:
After creating a blank template, create a full template:
Fill up a document template with texts, pre-written paragraphs, pre-written titles, so they will only have to click and rewrite, without the need to format or bother with styles and Cover pages and the lot
Educate the users: 2 sessions of 1,5 hour Word class can go a long way. It is a must.
Long post. One last thing: creating a complex Word template, you will be sailing a sea of Word bugs and annoyances. Even without writing macros, this won't be a walk in the park. (I for example gave up on making my TOC work in Office 2013, as after 3 days and 10 versions, it still kept on creating a maximum sized extra paragraph whenever it was inserted. Only in W2013. Still no idea why, but I let it go.)
Whatever you decide to do, best of luck, and have a lot of patience! :)
I'm interested in displaying 1-5 model instances using forms on a page using a grid similar to something one would find in a desktop database application. I understand I would need to use multiple forms or formsets but an additional requirement is that I'd prefer it to be in more of a grid format with each model's fields being display in columns with common field labels on the y-axis.
I should have the ability to edit multiple columns (so in effect, model instances) at the same time and then commit either the single column (model instance) or commit all. I'd also like to be able to highlight the changed cells that have changed to give visual feedback to the user that there are pending changes.
Sorry for the rather long list of requirements and I'm aware this probably requires a few different technologies/techniques to achieve. I'm throwing this out there because I'm asking this kind community for guidance on what components/technologies I should look at. If luck would have it, there would be some jQuery component that can handle this for me almost out of the box. If not, some guidance on achieving the editing of multiple model instances would be of help.
I will also need to build in versioning in case the data displayed on the view page is stale and to prevent overwriting a newer commit. I'd probably achieve the latter using a versioning field in the table that will perform the check and handle it accordingly.
Also, Flask and Django are both options for the engine and WTForms look to be promising at least at first look.
Thanks
There is no such ready to use solution in Django. Just create your custom form that handles as many instances as you want and do anything that you want, or extend formset.
I am looking for some general wisdom here.
I am looking for an elegantly simple way to limit the number of rows in a table that are presented on a page with a "view all >>" to get the whole table presented in the view. I considered all of the following,... some in combination:
two different partials,... one that lists a limited number of rows with a "view all >>" link at the bottom and a second that lists all with a "collapse >>" link at the bottom.
using jQuery
a css solution
ajax
Any links and / or snippets would be helpful in addition to your rationale for choosing one over another. I would prefer to minimize server / database requests without creating a voluminous coding monument to ingenuity of the programmer (me) :=]
Thanks!
UPDATE: Look here to see code written before that could be adapted. Many thanks to Neal for the jsfiddle.net resource.
A GREAT solution for big tables is a Grid. My grid of choice is DataTables
Grids solve a lot of problems: sorting, paging, filtering, ajax loading, and showing/hiding results. It's likely you're only talking about the limiting portion of the equation, but I'd submit that ALL the features have a value in interfaces, so they're all worth looking at.
Setting it up is easy and you have three options for data:
Build a proper HTML table with <thead> and <tbody> tags. The grid interprets the DOM and styles accordingly.
Provide a valid JSON string with table data. DataTables builds the HTML for you.
Supply JSON via AJAX. This also allows you to "pipeline" data to lookup data ahead of and behind the desired.
Datatables is JQuery driven, so you'll have to include Jquery and the DataTables code. There is also a bit of CSS to make things "pretty" That's it....pretty easy. Once you get the hang of it, producing a new DataTable from scratch takes 2-3 minutes. Considering the features, that's a minimal investment in your UI.
As to performance, I have a DataTable handling 2.5 million records without fail. It utilizes JSON pipelining, paging, sorting, and filtering (and a well-indexed MySQL DB) to maintain acceptable performance.
In a typical business application it is quite common to have forms that are used for searching.
Some basic features are:
A pane that contains the search criteria
A grid to display the results
Sorting on the grid
A detail page that opens when an item is selected in the results grid
What other features would you expect in a business application's search functionality?
Maybe it's a bit trite but there is some sense in this picture:
removed dead ImageShack link
Do it as it shown at the second example, not as at the 3rd one.
There is a well known extreme programming principle - YAGNI. I think it's absolutely appliabe to almost any problem. You always can add something new if it's necessary, but it's much more difficult to remove something what is already exist because someone already uses it even if it's wrong.
How about the ability to save search criteria, in order to easily re-run a search later. Or, the ability to easily, cleanly, print the list of results.
If search refining is allowed (given a search result, limited future searches to the current results), you may also want to add a breadcrumb system, so that the user can see the sequence of refinements that lead you to the current result-set -- and by clicking on a breadcrumb, return to a previous refinement stage.
Faceted search:
(source: msdn.com)
This is displayed in the area in the right ellipse. There are filters and the engine shows the number of results that will remain after aplying the filter. This is very useful and can be done without pain in some search engines, such as Apache Solr. Of course, implement this only if filters make sense in your task.
Aggregate summary info, like total(s), count(s) or percentages.
One or more menus, like right click context for the grid, a ribbon or menu on top.
Your list for the UI elements is kinda good. Export, print (asking them whether it is really necessary to print this?), category/tag and language selection is worth to consider. Smart and working pagination (don't forget ordering).
Please do not force a search to open in a new (or even worse, always in the same window). Links of search results should be copy-pastable (always use GET),
But it really matters to have a functional (i.e. a really good) algorithm. Mostly I google company websites, because their search engine is, cough, awwwwkward. Looking for a feature chart, technical spec, pricing etc. one is not interested in press releases and vica-versa.
Search engine providers offer integration into company websites.
Use Auto-complete wherever possible on your text input fields.
If using selects or combo boxes with related information try and use chain selects to organise the information.
Where results depend on location try and serve relevant results.
Also remember to keep the search form as simple as possible even down to one text field. To refine the search you can have an alternate form as an "Advanced Search interface".
Printing, export.
A grid to display the results
Watch out not to display results a user is not authorized to see (roles / permissions / access rights).
A detail page that opens when an item is selected in the results grid
In case a user attempts to circumvent the search page links and enter some document directly, again, check out for permissions.
Validation, validation, validation.
It should be very hard, near impossible, for me to run a query that makes no sense. ie, start date occurring after an end date.
Export a numerical dataset (even if it only has one numeric column - so just make it so by default) to CSV for import into Excel (people love this function, even if only 1% of users seem to use it with any regularity. Just ask yourself when's the last time you highlighted something for copy-n-paste. Would it have been easier to open a CSV?
Refinable searches (think Google's use of site: -). People who use the search utility a lot will appreciate this. People who don't won't know it's not there.
The ability to choose to display 1 records, 5 records, 100 records, 1000 records, etc. "Paging" I believe is what we most commonly call it ;).
You mentioned sortable grids. Somebody else mentioned auto-sum or auto-count. Those are good if (once again) you have largely numeric data. But those are almost report-oriented functions.
Hope this helps.
One thing you can do is have a drop down of most common searches in plain english. e.g. "High value sales in New York in last 5 days". This is the equivalent of user selecting an amount, the city, date ranges etc. done conveniently for them.
Another thing is to have multiple search criteria tabs based on perspective of the user. Like "sales search", "reporting search", "admin search" etc.
ALso consider limiting the number of entries retrieved in the search and allow users to do more narrow searches. This depends on the business needs however.
The most commonly used search option listed first and in a prominent location.
I think your requirements are good. Take a cue from Google. Google got it right. One text box where you type whatever you want, and your engine spits out the answers. Most folks will try this, and if the answers are good enough, then that is what they will use. In the back-end, you'll probably want to flatten all of the data into a big honkin' table and then index it or use a SQL query with "LIKE" in it.
However, you will probably want to allow the user to refine the search. For this, have a link to "Advanced Search" and use a form there to specify filter criteria. This lets the user zero in on the results if basic search is not good enough. For the results on th is page, you will certainly want to have sorting on key fields, but do it after you have produced the initial result set.
It depends on the content that you are searching for.. make it relevant :) Search always look easy but can be incredibly difficult to get right.
Not mentioned yet, but very important I think - a search that actually works. This item is often neglected and makes the rest a bit moot.