I am interested in the possibility of providing a set of validation rules for user input values.
So for example a textbox called 'Today' might require a rule that looks something like
IsADate() and (Value >= Date())
My problem is that nobody can tell me what rules are needed. In order to deliver a solution I need users to be able to decide for themselves what rules they want.
It occurred to me I could create a database table containing a separate field for each input - each field having a user-definable check constraint and data type, but this is too limiting (in terms of how many rules I can define)
I could allow the users a UI which would effectively allow them to provide a where clause which then executes a select count(*) from dual where <plugin logic>
And then I started to think I am just database-obsessed.
Any thoughts?
I did something similar using application code and business logic. If you create a token parser based on some of your common business objects that you can load and evaluate for various views or forms then you can start to create a collection of custom variables.
#Date.CurrentDate
#Date.LastQuarter
#Customer.LastInvoiceNumber
#Customer.ZipCode
#Customer.MaxNumberOfOrderItems
If you expose your tokens in a list of rules for a particular field you can build a custom component that will let users build expressions like.
Value [ Greater Than ] [ #Customer.LastOrderNumber ] [ AND ]
Value [ Starts With ] [ #Customer.CustomerID ]
In my opinion this would be more flexible than using sql for validation.
If users have limited of Delphi / Pascal syntax knowledge, a quick solution is to let them create the validation as a pascal function, and use TJvInterpreter from JCL library.
Easy to use, simple to implement, that's a good work around !
Reference:
http://jvcl.delphi-jedi.org/JvInterpreter.htm
Related
I need some architectural advice. I'm more into java, but trying to get up to speed with Ruby-on-rails. In the app I am building I need a convenient place to store some dictionary values that will be later used in various places of the application. These will be usually key value pairs - e.g. list of values to be used in select list.
The main objective is to keep this logic in one place of the application.
I am considering following options:
Store values in the database - i'm kind of reluctant from that, as values won't change very often.
Put all of the values in one class. In JAVA I'd have some static properties in one class holding this values (e.g. call Utils.getStates() will return list of states). How to do it ruby way?
Have some .yml file with values - read from the values. How to do it? I guess I have to parse the file in the initializer, but is there any tutorial how to do it?
Precise example? Let's say that have a model that have a field called "Type". Type can be: ['Type A', 'Type B', 'Type C'...]. And of course, for each type I want to have key and value.
I'd appreciate some suggestions about how you solve this problem in your apps.
Thanks,
Maciek
How often does the list change? Is it acceptable to have developers involved each time a value changes (updating code, re-deploying the app)? If the answer is no then store the values in a database.
Is the list of values reuseable? Then a gem or a yaml file with an initializer might be a good choice.
Is it just a small list and does not change often? Then you might want to consider a constant.
I think in Rails any data that would change at runtime and needs to be persisted, would normally be stored in the database. I think that would be the "rails way". You could save the data to yaml or json file, but that would not follow the normal flow of the MVC pattern that is so common in rails
I would like to speed up some of my admin-generated modules by hydrating doctrine results with Doctrine::HYDRATE_ARRAY. Is this a good idea? How can I do it?
I don't think that you can do it that easy. All calls in the default admin generator theme use the Doctrine object (i.e. $model->id, and not $model['id']. To use arrays you would probably need to recreate the default theme, as well all calls that retrieve the objects.
Oh, and also the Admin Generator uses the generated forms as it's base for generating the displayed forms.
You would probably be better off optimizing other ways. Make sure you have to correct client side caching headers, optimize the sfViewCacheManager on the server side, use APC, use the doctrine query cache, etc...
This could include some more custom work (for example leveraging the view cache manager), but significantly easier to implement.
I agree with Grad van Horck. Also, make sure your index pages are using the minimum number of queries (easy to see in the development environment's web toolbar). Most of my modules are much more efficient after I create custom table_methods with the proper table joins and also include ONLY the fields I need to have loaded into the object.
I have a question about Pylons's request.params, which returns a MultiDict object.
Does request.params preserve the ordering of the GET parameters in a reliable way?
For example, if I were to visit http://localhost:5000/hello/index?a=1&a=2 and call request.params, could I guarantee that the MultiDict object returned would be in the following order?
>>> request.params
MultiDict([('a', '1'), ('a', '2')])
I'm guessing not, because Python seems to have a separate OrderedMultiDict object used for, well, ordered MultiDicts.
If not, is there any other way I can obtain the GET parameters and preserve their ordering in Pylons?
As I remember, even if you can get Pylons to preserve the ordering, you're not supposed to rely on that kind of behavior because not all user agents (browsers, bots, etc.) preserve ordering either and that's outside your control.
If it's part of the HTTP spec, it's not reliably followed... I doubt it is.
For example, suppose the user agent is a Python application which handles query parameters using dicts.
This is a new application, and I have an index method on a Search controller. This also serves as the home page for the application, and I'm trying to decide if I am headed down the wrong path from a design pattern perspective.
The method is already 35 lines long. Here is what the method does:
3 lines of setting variables to determine what "level" of hierarchical data is being searched.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
A 10 line section to redirect to one of two pages based on:
1) If the user does not have access, and is signed in, and has not yet requested access, tell them "click here to request access to this brand".
2) If the user does not have access, is signed in, and has already requested access, tell them "so and so is reviewing your request".
Another 10 lines to build the dynamic arel.
I can't get it straight in my head how to separate these concerns, or even if they should be separated. I appreciate any help you can offer!
Summarizing what you've said in something codelike (sorry, don't know ruby; consider it pseudocode):
void index() {
establishHierarchyLevel();
if (requestIncludedSubdomain())
fillSubdomainFields();
else
fillNonsubdomainFields();
if (user.isSignedIn() && !user.hasAccess()) {
if (user.hasRequestedAccess())
letUserIn();
else
adviseUserOfRequestUnderReview();
}
buildDynamicArelWhateverThatIs();
}
14 lines instead of 35 (of course, the bodies of the extracted methods will lengthen the overall code, but you can look at this and know what it's doing). Is it worth doing? That really depends on whether it's clearer to you or subsequent programmers. My guess is it's worth doing, that splitting out little code blocks into their own method will make the code easier to maintain.
That's a lot of variables being set. Maybe this is a good opportunity for a module of some kind? Perhaps your module can make a lot of these decisions for you, as well as acting as a wrapper for a lot of these variables. Sorry I don't have a more specific answer.
Without your code it's somewhat difficult to suggest actual fixes, but it definitely sounds like a really wrong approach and that you're making things much harder than they need to be:
3 lines of setting variables to
determine what "level" of hierarchical
data is being searched
if there is a search form, I would think you would want to pass those straight from the params hash into scopes or Model.where() calls. Setup scopes on your model as appropriate.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
This seems to me like it should be at most 1 line. or that in your view, you should use if statements to change what you'd like your output to be depending on your subdomain.
A 10 line section to redirect to one of two pages based on:
the only thing different in your explanation of the 2 views is "whether the user has requested access" surely this is just a boolean variable? You only need 1 view. Wrap the differences into 2 partials and then in your view and write one if statement to choose between them.
Another 10 lines to build the dynamic arel.
It might be necessary to go into Arel, but I highly highly doubt it. Your actual search call can in most cases (and should aim to be) 1 line, done through the standard ActiveRecord query interface. You want to setup strong scopes in your models that take care of joining to other models/narrowing conditions, etc. through the ActiveRecord Query interface.
i need to localize a Reporting Services-report (.rdlc) and i would like to do it using a ressource-file (.resx).
I found pages like this and that and they use custom code to achieve their target.
But pages like Setting the Report Language Parameter in a URL give me the impression that localization in reports is possible without custom code.
So, it is possible to localize a Reporting Services-report without custom code ?
If so, is there a tutorial that explains how it's done?
What in the report do you want to localize?
values from the database? Those should be retrieved from the database in the appropriate language already
fixed labels and textboxes on the report? I have not yet seen any compelling way to doing this - you can either have
one report "skeleton" / template per language (and pick the one you need)
if the number of elements is manageable, define report parameters which you can set from the calling code, to set the labels and texts
use some custom .NET extension for handling localization
It's not really an awfully pretty picture, indeed - I'd be most interested in better solutions myself! (I typically need to support 3-4 languages for any report - and I'm using only server-based .RDL files, no .RDLC, so any localization that depends on client-side resource files is not usable in my case)
I would add one method when it comes to labels and textboxes:
Create a placeholder element within the textbox and use Expression field to
use a Switch clause , switching on the Language parameter.
It's not superpretty, but also works pretty well for 3-4 languages
I am passing parameters to the report for labels etc, and after adding the parameters to the report (using the menu option Report -> Parameters in VS2008) you can then use the values of these parameters to localise the labels. This is workiiing well enough, although it would be nicer to be abkle to refer to resource keys immediately from your form labels etc.