Child pages
  • Adjustments to content block numbers
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/5fe9214303208f70#

Currently we use integer numbers to identify content block on the page like this: <inp2:st_ContentBlock num="5"/>. We don't use content block name, since numeric field can be accessed faster in database.

Recently I came across need to place content block below each field on front-end form. To solve my case I passed "prefix" and "field name" as content block number and applied "crc32" function to that string to retrieve proper number.

Related Tasks

INP-739 - Getting issue details... STATUS

19 Comments

  1. I think that the way how in-portal handles user sessions now is quite
    strange. Why should session be removed when user loggs-out?
    When session is created (user first opened the page) - it contains data
    associated exactly with that SESSION
    , where the last "session" word actually means some continuously
    repeated action (usage of the site).
    Sure, session needs to store information about user status (logged-in,
    not logged-in), but it shouldnt depend on that. There can still be need
    in session-stored data after user logs out. Session should only be
    removed when it is expired.
    What do you think guys?
  2. Hi Nikita,

    Thanks for your post and thoughts.

    You didn't specify which version you have tested on - 5.0.x or 5.1.x?

    A few notes to add:

    a. Starting In-Portal 5.0 we have changed things in session handling so we
    only create session when it's needed to store some user specific
    information, for example you are not logged in (no session created), but get
    to the registration page where you see a Captcha Image. Obviously we have to
    store that Captcha code somewhere and this is when the Session will be
    created and stored in a Cookie. Similar with the sorting of the lists - if
    user selects to change the sorting it will be sorted in the session (note
    that this changed in 5.1.0 again for better results).

    b. OnLogout I believe we change "u.current_id" to -2 (which is not session
    depended), destroy the old session and create a new one (all done in Destroy
    method of InpSession class).

    Would you please provide some real life examples were it failed to work
    right now? This way we can look at both up and down sides of this.

    Thanks.

    DA.

  3. I came across this issue when i was working on facebook connect
    integration. As far as the "connection" it self is made on clients side
    (client loggs in to the facebook, receives cookie there and then this
    cookie gets passed to our site, telling us that the user is really
    logged in to the FB) you always need to refresh page at least twice when
    user loggs in or out. First time user goes to the FB page where his
    session gets created/cancelled, then hi is redirected back and informing
    our site regarding his current FB session status. Because of this there
    are things that sometimes could be passed only via session. And what i
    have faced - is, when logged in user (something already is stored in the
    session at this point) loggs out, i loose everything i had stored in
    that session.
    I hope this helped understanding what i was speaking about.

    This was seen on in-portal 4.3.9 but im going to test it out on newer
    versions.

  4. Thanks the details Nikita.

    Alex, let's think through the case of what happens if we simple don't
    Destroy and Create the session on Logout, but keep using the old one?

    DA.

  5. Don't have any specific opinion about that. We need to look on other
    websites and how they handle session, when user hits logout.

    For example there should be other websites with facebook integration and
    session handling too. Let's analyze how they solved session problem.

    Maybe there is some trick in facebook integration.

  6. Hi Alex, Nikita,

    Okay let work on this together.

    Nikita, we would need more of your participation in the process. Let's
    start with finding some sites were we can follow the idea how their
    are doing Facebook Connect and what happens with the Session on User
    Log out there.

    Once we have about 2 different sites we can take a closer look and try
    pull more ideas from there.

    Please update here on the progress.

    Thanks.

    DA.

    On Fri, May 14, 2010 at 12:04 AM, Alexander Obuhovich

  7. I think we can't hold the whole logic without checking how SSO works with
    Facebook.

    2010/5/14 Dmitry Andrejev <dandre...@gmail.com>

  8. Hello Dmitry!
    There are no problems with Facebook Connect actually, i have solved them
    when i was working on it. This story was submitted just as a real life
    example case to describe what (in my opinion) is working wrong way in
    our sessions mechanism.
    Im not sure that you have understood me correctly, so i will try to
    explain again (btw i have tested this on In-Portal 5.0.2 and problem is
    still present).

    How it works now:
    1) Log-in to the In-Portal (get authorised with login/password through
    front-end);
    2) have something stored in the session;
    3) log-out;
    4) notice that ALL data previously stored in session is lost permanently.

    How it should work:
    1) Log-in to the In-Portal (get authorised with login/password through
    front-end);
    2) have something stored in the session;
    3) log-out;
    4) have ALL the data previously stored in session to stay available,
    only individual variable values should change to mark user as being
    logged-out (user_id etc).

  9. I'll wait for other facebook integration research results here.

  10. Hi Nikita,

    Thanks for clarifying on the question - yes, we do understand your point,
    but before making those changes we really need to look into all aspects of
    this and would be great to look at some other systems (PHP frameworks)
    integration with Facebook.

    Also, here is what you can do as your own research. Do the SVN checkout of
    In-Portal 5.1.0 (I think all modules so can see how all works -
    http://source.in-portal.org/w/in-portal.full/branches/5.1.x) and setup
    Facebook Connect integration in your local environment. Then try to
    experiment with adjusting Destroy method of InpSession class so we don't
    kill the session and create a new one. Then do numerous tests of the whole
    system/site to see if anything else got affected by this. This will be VERY
    helpful if do that.

    Let us know if there are any issues with the setup or you have any
    questions.

    Thanks.

    DA.

  11. what do you suggest here?

    2010/8/9 Alexander Obuhovich <aik.b...@gmail.com>

  12. Hi guys,

    Looks like we have came across this topic again which why I am writing here
    again.

    Summary:

    We should adjust *<inp2:st_ContentBlock num="5"/> *tag to accept both "num"
    and NEW "name" param (will be the same) with ability to specify ANY symbols.
    In result NAME value will be converted to CRC32 and stored as number in the
    database. In case if both as specified - NUM will win in order to keep
    backward compatibility with current (older) In-Portals. We are going to
    encourage the usage of NAME param by giving a NOTICE that "num" param
    is deprecated and will removed in a future.

    Task:

    Add "Name" parameter to st_ContentBlock tag

    INP-739 - Getting issue details... STATUS


    DA.

  13. Alex, please take a look here and feel free to make notes/corrections
    if I have missed anything.

    Cheers!

    DA

  14. I'm actually against making notice about depricated "num" parameter, since
    both "name" and "num" parameters have equals value for given tag. User can
    use one or another, based on situation.

  15. Okay, it's not a deal breaker for me.

    Please make your change to the task then!

    DA

  16. Done. It seems, that you like words like "show stopper" and "deal breaker"
    :)

  17. Thanks for updating, Alex!

    About your last comment - not quite - in most cases I use NOT before them,
    which means that there is no need to argue about something that's not
    important.

    DA