Jump to content

ginerjm

Members
  • Posts

    6,906
  • Joined

  • Last visited

  • Days Won

    99

Posts posted by ginerjm

  1. A simple returned message can do this for you. Why not let the called script return the exact message you want to pass to the user instead of making the caller deduce some msg from whatever you are proposing to do? Let's face it - if the rejection is based upon a logical error or programming error then you need to re-write something. OTOH if it's simply a matter of a business logic error or user-input error, shout it to the user!

  2. Alternatively, I am sure I could have the server return something like:

     

    echo(json_encode(array('status'=>0, 'error'=>'Your input must be between 40 and 80 degrees')));and then use the plugins success callback to present the error.

    Again - Why Why Why?

     

    What is wrong with your ajax-called script returning a simple error message to the caller? Or is there something else you are not telling us, like this is destined to be a universal target for other apps to use and the error message has to be more generic instead of specific?

  3. Yes, an ajax request.  Should have said so.

     

    Some jQuery plugins (x-editable for instance) have an error callback and are built to display a error message when receiving any response other than 200.  This allows the server to do the following:

    
    http_response_code(400);
    echo('Your input must be between 40 and 80 degrees');

    If desired, one could set up the error callback to display a general service unavailable message if code 500 is received.

     

     

    Alternatively, I am sure I could have the server return something like:

    
    echo(json_encode(array('status'=>0, 'error'=>'Your input must be between 40 and 80 degrees')));

    and then use the plugins success callback to present the error.

     

     

    Just trying to better understand the implications of both approaches.

  4. So now that it turns out to be a response from/to an ajax request, my point remains the same.

     

    Notion - you began this topic with the concern about using the "correct" header for a response. Again - why use something that today you can't even name for returning an inter-application reply? Just send back an error message that your caller will understand and react appropriately to. Why all the drama? Why should your two pieces of code have to use headers to convey a message? Seems like overkill to me.

  5. A basic tenet of good db design is never to store a data value in a table where the value can be determined easily from other pieces of data in that same table. A simple straight-forward calc such as yours relying on fields stored side-by-side with this calculated field is wasteful, unnecessary and causes undo repeat calcs whenever one of the inputs to the calculation is modified. As pointed out already, the profit can ALWAYS be calc'ed as part of a query and this can always be counted on to be correct. What happens when a value is edited and the recently-written update job that does it fails to re-calc the profit using the new value?

  6. An erroneous http header is great?

     

    I dunno what you're doing down there, but have fun at whatever it is. I know that if I was using a website and it spit out headers for various diff codes instead of just telling me in plain English what I did wrong, I wouldn't frequent that site anymore.

  7. A form builder? You mean to be used in your future endeavors when you need to write a script that will utilize a new form? Or to satisfy a requirement that you build random forms all the time using some massive set of varying inputs? Both seem kind of large tasks for a newbie to be experimenting with.

     

    Let's face it - given a task you design a form and write the html for it and use it in your php script. When will you need to re-write THAT particular form again that either a) you can't copy it, or b) well, there is no b. Forms are unique to each application in that you want your own titles for them, your own name= attributes and your own data requirements. If you actually have a future plan that will allow you to re-use the same sets of fields for your future forms then I guess this will work for you, but I think it's a long ways off to be using as a learning experience for html/php/sql knowledge.

     

    Just my $.02.

  8. You could build your query statement dynamically as you loop thru your input fields. Use vars to represent the field names just like you will be doing with the corresponding values

     

    Are you sure you have thought out this design well? Seems kind of crazy.

  9. Let me pose another question. Just what are these "sessions" you are referring to? Are they truly "PHP Sessions" for which you are trying to make a system to keep track of them all in one session? Because if so, I don't think you can do this since sessions are private and separate for each user by design.

  10. Don't understand your logic for having this kind of setup. Can you give us some background before we waste time giving you a possible solution that turns out to be unusable? Sounds like you have a commerce site where you want to monitor multiple shopping carts for one user. That doesn't seem right.

    • Like 1
  11. Session_start is most likely the culprit. I wouldn't go so far as to recommend it in every 'include' file, but it does have to go near the start of every script that you pass control to. If you are using a header() command to trigger your members script, then definitely you need a session_start at the top of that one.

     

    It's simply a good habit to put it at the beginning of every independent script you write.

  12. Does one really need a "PDO framework"? PDO is pretty simple to understand, and requires only a few statements to use. It's a set of functions that does everything you need. What will a framework accomplish for you that your own code can't do?

     

    Guess I never understand why people here are always looking for ways to encapsulate a basic feature of web development with some 'tool' (framework in this case, object/classes in others) when the standard php language promises so much. You write a statement and prepare it, then you assign your parameter values via either a bind or an array to be used in the execute() call and then you loop thru the results with a simple while calling a fetch. Oh - and the connection is a short set of code that you write once and store off-root and include wherever it is needed.

     

    Just my $.02.

  13. Having now seen your duplicate posting (!!!) I will offer this..

     

    1 - as was already mentioned, turn on error checking. (See my signature)

    2 - Where you try to insert a record you reference the $image var. That has not been defined. And what exactly are you trying to store in your db - an image file name? Did you ever save the uploaded file someplace? I don't see any code for that. And since you never assigned a value to $image, you're probably getting an error but not seeing it displayed.

  14. Assuming that the questionnaire contents are in a table which contains not only the questions but the title and a date field that you can call "release_date". Set that field to be the date you want it to be available and maybe have another field to close it so that when the page is called for and you query your db you select only those who have a release date and close date within your current window of time, ie, release <= today and expire >= today.

  15. So - your while loop echos out both li tags for each row that is returned. Why? (And I've never seen a list used in such a way as to contain 6+ divs, two imgs, a p and an a tag as well as whatever else is in all that html.)

     

    If you only want one li per row, then only echo one li per row. Use a switch mechanism to alternate which one is used if that is what you are saying.

     

    Try:

    while......
    {
    ...
    ...
    if ($alpha)
    {
    echo (the alpha li tag)
    else
    echo (the li tag w/out alpha)
    $alpha = !$alpha;
    }
    ...
    ...
    }
    

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.