rubenski

Hi, I think I ran into a design problem with the PHP application I'm building. I have this function called validateFormElement() that takes FormElements polymorphically. A FormElement can be a FormElement or a TextFieldFormElement, or a TextAreaFormElement, etc. Inside the method I use a factory to obtain the proper FormElementValidator. Passing a TextFieldFormElement to the validateFormElement() function will make the factory return the specific TextFieldFormElementValidator. function validateFormElement(FormElement $formElement){ $validator = FormElementValidatorFactory::getInstance(get_class($formElement)); // .. if-elsing here } But now I don't know what functions I can call on the $validator. Each type of Validator returned by the factory has different functions and now I find myself if-elsing to see what type of $validator I have and consequently what functions I can call on $validator. This is not good. Is it? How would you do this? I need a specific validator for each type of $formElement. The issue is not that I can't get it to work. If-elsing does the job, but it just seems... wrong.

What I understand from your post is that you want to store Users and their appearance and religion. The appearance properties are unique to a user and should therefore be stored in the user table. The question you should ask is whether a lot of users will share the exact same appearance. If the answer is no (which it is), don't split it of into a separate table. Appearance properties are very unique to a specific user. Religion on the other hand is a property that is shared by many users and therefore qualifies for a separate table. Here is what I would do: Table User - userID (primary key, autoincrement) - pswd - email - height - weight - hair_color - another_user_property - religionID Table religion - religionID (primary key, autoincrement) - name - number_of_followers - is_monotheistic - another_religion_property The religionID in the user table is a reference to a row in the religion table.

Hello, Imagine you have a 'car' system. It has a HTML form for entering cars (brand, name, year, color, etc), but you also want to allow client programmers to enter and edit cars programmatically through a CarManager object, for example through CarManager::addCar(Car $newCar) Ideally, I want to use the addCar() method for each Car insertion, either through the HTML form or through client programmer's code, but I think both have different requirements for validation information. - The HTML form requires a valid/invalid indicator and in case of invalid input a set (array?) of error messages that can be displayed under fields that contain erroneous input. The form wants to know all errneous fields and their specific problems at once, so it can display all problems to the user at once. - The client programmer would probably be most familiair with an Exception that is thrown when invalid data is found in one of the $car's fields. I currently return either 'true' or an array of FieldValidator objects containing per-field error messages from the addCar() method. This is perfect for the HTML form, but not for client programmer code. Next possible solution is to create a custom Exception containing a generic error message and an array of per-field error messages? What would you do?

Hello everyone, I am trying the PHP reflection API and I ran into two questions. I have the following code: $modelReflector = new ReflectionClass('Course'); $methods = $modelReflector->getMethods(); foreach($methods as $key => $value){ echo "method: " . $value->getName() . "<br>"; } This code prints the methods in the Course class. My questions are 1. Why does getMethods() take no value or a 'long' value? Can't I pass in a regex somehow to select only setter methods? 2. I noticed that my editor doesn't know the type (and associated fields and methods) of the $value object in the foreach loop. I know it's an object, I found out that there is a getName() method because php.net says so, but my editor doesn't know it. Is there some way to define the type for an array? Or can I cast value to the appropriate type inside the foreach loop? Thanks!

[quote author=akitchin link=topic=104035.msg414786#msg414786 date=1155430169] as i said earlier, i'll guess that a validation class is in order.  you'll be running input validation fairly integrally in any application, and so it's probably easiest to have it bundled together and just extend any overall application class with it. [/quote] This is basically what I thought too. However, when I think of it again, it doesn't seem right. If I create other classes like ehhhm.... 'Member', 'Appointment', etc I'd have to create a separate Validator class to extend each of them. These separate validator classes would all contain nearly the same code. It sounds logical to me to create a separate validator class that contains all validation logic and that can be used by all application classes.... You think it would be wise to put the Validator class on top and let any application class (Room, Member, Appointment) extend it?

Hi folks. I am creating a three tiered system with a HTML front end and a mysql DB. I want to create a simple application that will store and retrieve information about rooms that are for rent (area, location, description, price_per_month, etc). So far I have implemented - a simple data class that connects with MYSQL and fires insert and update queries. (class RoomData) - a business logic class that manages room fields (class Room) - a HTML view containing a form that allows the user to enter a new room into the database. [img]http://www.tekstenuitleg.net/class_schema.gif[/img] Now, what happens when someone presses the submit bitton on the form? Obviously, the application must validate the form data first. This is where I get stuck, OO design-wise. Where should I put the form validation code? In the Room class? Or would it be wiser to create a separate input validation class that extends Room? What is your design strategy for input validation?