I am using Symfony 1.3.2 with Propel ORM on Ubuntu 9.10.
I am writing a registration form, which requires a user to provide a user name.
I want to impose the following restrictions on the choice of names:
That the name is unique (i.e. is not already in use by someone else
The name is not in a list of offensive names, stored in a database table
For the first requirement, it is easily done by using the sfValidatorPropelUnique validator.
The challenge however lies in implementing the second requirement AND COMBINING requirement 1 and 2 into a single validator.
I suppose I could write a custom validator to do this, but I am wondering is there a better way to do this (i.e. using the framework, and not "rolling my own" solution ?
Can't think of a ready symfony validator solution to do that, and in any case, you'd need to write the database call separately.
I'd go with 'rolling your own solution' but perhaps someone more experienced has a better idea.
There's something in this doc about Propel autocomplete which might give you some ideas if you're minded to explore further:
http://www.symfony-project.org/cookbook/1_2/en/make-a-choice
... courtesy of the sfFromExtraPlugin, but I'm not even sure if that's 1.3 compatible.
You have to use sfValidatorPropelUnique and a post validator, see here
Related
I'd like to add filtering and sorting to my GraphQL types (using graphql-ruby gem).
I've been looking for existing solutions for that and the only reasonable option I've found is creating a custom resolver.
The problem with this approach is that I "lose" Active Record capabilities like using custom methods on the models for filtering or field resolution.
Has anyone come across a decent (and existing) solution for this?
It's worth mentioning graphiti which offers these out-of-the-box but diverts from the GraphQL spec and uses JSON:API instead. It's great but I'd like to benefit from GraphQL subscriptions and built-in authorization.
There are some gotchas with respect to having a generalised solution for sorting and filtering and the GraphQL standard. It's hard to define a concrete schema for a set of arguments that could easily apply to different types well. Because you might naturally have something like sort: Enum[name_asc, name_desc, country_asc, country_desc].
If you are happy with that limitation, and willing to receive your params as some kind of generalised sort: String and write code to ensure what is sent is a valid value. Then you can use a Connection (https://graphql-ruby.org/pagination/using_connections) for this purpose.
It is very easy to create tickets on JIRA with almost no restrictions - which is why I am wondering if it is possible to force some kind of template or other limitation so that people create tickets with required fields.
I am unaware if this is possible and Google doesn't bring up much
The easy answer is yes, but there is a lot involved in creating custom request views that require admin access. You may find the following information helpful...
https://confluence.atlassian.com/doc/create-a-template-296093779.html
Field Configurations (which are applied through a Field Configuration Scheme) allow you to make specific fields required for a given Issue Type in a given Project.
See: https://confluence.atlassian.com/adminjiracloud/changing-a-field-configuration-844500798.html
You can do this type of restrictions and also change the aspect of the screen the users interacts with by using the Script Runner plugin, in particular by using the Behaviours feature of such plugin. You can also write Groovy code to customize almost every aspect of the form and do input validation/templating.
At the moment ’m building a web app using Ruby on Rails. I try to get my head around the data model and database part. To make it easy to understand I’ll use IFTTT as an analogy:
In the app, the user can add different recipes, for example:
Facebook — Twitter
Weather — Send email
You name it...
Of course every recipe has its own fields and options. So the user can choose multiple recipes from the library and set options to every recipe. The library of recipes is defined in code.
I have a few questions regarding this setup and would be happy if I could get some directions:
Is it smart to serialize the options of a recipe into a single database field? Every recipe has different fields and I don‘t want a database table for every recipe type.
Or is it better to create a ‘key-value’ table with all the options of all the recipes?
How to handle validation? Can Virtus come in handy?
Is a NoSQL database a good fit for these kinds of applications?
Are there best practices for these kinds of applications/data models? Any help is welcome.
Thanks!
Rens
Not sure if SO is the best place for really general questions like this but I'll take a swing
1 && 2) Personally I'd give the recipe table an action_taken field, probably as a string, and fields for all the available, resulting actions as booleans. Then the only thing you really need to be careful of is making sure the action_taken field remains uniform
3) ActiveRecord has a pretty fleshed out validation suite built in. You can validate based on presence, uniqueness, inclusion in a set of elements, etc. You can also extra validations on the database if you feel like being extra safe
4) I would use PostgreSQL, seems to be the community standard so probably the easiest to get support with if you need it
Hope this helps
I'm using devise. I modified the user fields with no problem. I need to access certain users, and modify their info. For example, let's say that the user "pete" should have the field "type" changed to "active". How do I do that? it should be just accessing the database and modify that field, but I can't make it work. I mean, there are tools to modify databases, but what is the rails way to do it?
I don't need a tool or script or modify the code, it's a small database and very few changes. Once I understand this, I may do something more general.
The typical rails way to operate on your data like this is to write custom rake tasks. The great Ryan Bates has a great screencast on the topic as well: http://railscasts.com/episodes/66-custom-rake-tasks.
If you do not want to do that, and the fixes you are making are really small, then you can do them via the rails console. More on that here: http://railsonedge.blogspot.in/2008/05/intro-to-rails-console.html
If you need the actual code of how to do that, it may look like this:
pete = User.find_by_name('pete')
pete.update_attributes(:type, 'active')
on the last projects i've started, I wondered if I should use the admin generator or not. My usual choice is to not use it, as some developers suggested to me, "unless it's for quick backend prototyping and submission to client", they said. Currently i'm starting a project and i'm in the situation that the client need the backend very fast to start loading lots of data, and i'm doubting about using the admin generator or not. I would use it if needed simple form fields. But one of my models must have multiple images, and maybe I need a more complex view that allow the client to load N images, so the admin generator maybe it's not the best choice, but it seems fast, it seems to save time and that's what I need now, time saving!
The project is very simple, it's just a Product model with multiple images and multiple sizes and belongs to a simple category.
What do you think? What would be the best option for this? And where do you think that makes sense to use the admin generator or the regular module generator?
Thanks in advance!
Regards.
I use the admin generator as much as possible. It is really designed to be great for the "backend" of your website-- the administrative screens which authors and editors will use to maintain the app. Any module that needs to be user-editable and is simple cries out for the admin generator.
Recently I have been starting everything with the admin generator so that there's a working prototype to build data with. Then I select certain modules or views that need more magic sauce, and build them out with more customization.
Remember, you can add views and forms to an admin generator module. On my last project I used the admin generator for the "edit" action of my main object but added "show" methods similar to a non-admin-generator form-- adding an executeShow() action and showSuccess template.
The other thing to keep in mind is that the admin generator is only a generator. It writes a bunch of code for you in cache/frontend/env/modules, but you can override any of it by building the equivalent code in apps/frontend/modules/. If you find one part of it that you can't configure with generator.yml, you can copy the file out of the cache into your module dir and hack away. I prefer to take the "out of the box" admin generator as far as possible before customizing it, though.
i've been working with symfony for quite some time now and i've been using the admin generator for simply and complex situations. It's true that it saves time when developing CRUD modules, but i dont think that is not advisable for complex cases.
I think you should use it and also learn the power of customization the generator gives you. If you have complex Forms, leave that for form classes to manage and as you said, if your forms a quite more complex to render, well you should only take care of the rendering of that only segment of the view.
But, if you decide to make if without it, you should start thinking about creating all the view from scrap, that in my case takes quite time ( i'm not so versatile wiht css).
But this is only my opinion, hope this helps you make a more rational choice!