• collective.amberjack discussion

  • Hide step if condition callable returns False

    from vincentfretin on Aug 22, 2009 09:55 AM
    Hi,
    
    Nice work guys.
    
    Can we rename "validation" by "condition" on a Step?
    
    On a step, when the isVisible method return false, we should hide entirely
    the step instead of include a warning box, no?
    
    What I want to do is for example
    add to tour2 all the tour1 steps and when you execute the tour2 and the
    folder is created then you only get the tour2 steps.
    If the folder is not created, then you get all the steps for tour1 and
    tour2.
    
    I think you can add a common step to all tours with describe how the user
    have to login if he's not authenticated. I suppose this is what you want to
    do, right?
    
    
    Vincent Fretin
    
    
    Thread Outline:
  • Re: Hide step if condition callable returns False

    from massimo on Aug 24, 2009 07:23 AM
    Hi
    
    On Sat, Aug 22, 2009 at 3:55 PM, Vincent Fretin <vincent.fretin@...>wrote:
    
    > Hi,
    >
    > Nice work guys.
    >
    > Can we rename "validation" by "condition" on a Step?
    >
    
    initially we called it "condition" then we moved to "validation" since we
    thought that is not just a precondition, but in some way, is a kind of
    validation of the step. but condition is a good choice!
    
    we are also thinking to evolve it in a future to something more
    structurated. for example: the "create a page" tour cannot be startd if you
    don't have "/myfolder" already created.
    so, the viewlet should
    - warning the user (and we need also a description of the "problem"),
    - put the steps in a disabled mode
    - propose to him the tour(s) that he should complete before continuing (for
    now I would just tell to the user to re-run the tour).
    
    
    > On a step, when the isVisible method return false, we should hide entirely
    > the step instead of include a warning box, no?
    >
    
    sure. we just went out of time :)
    
    
    >
    > What I want to do is for example
    > add to tour2 all the tour1 steps and when you execute the tour2 and the
    > folder is created then you only get the tour2 steps.
    > If the folder is not created, then you get all the steps for tour1 and
    > tour2.
    >
    
    I didn't think to tour's aggregation in that way, but it's an option.
    
    imho, we have two different target and so two different ways to do things.
    if we think to complete the PLIP, we want to create tours for Plone then we
    can assume that:
    - the instance is "just a try"
    - the tours available ships with plone
    - you just have a predeterminated set of paths and scenarios
    
    If we think to aj to "a way to create tours in plone" then we should think
    that:
    - given a set of tours, an power user (not a programmer) would aggregate
    them in different ways. many paths, many scenarios
    - more than a user can run a tour in the same moment
    - you can develop and release your tour for your product or internal to your
    organization.
    
    Actually, I would stay in the middle: keep things as simple as possible, but
    think in advance to possible scenarios and try to avoid refactoring.
    
    in my idea, every step in a tour should have a validation (or condition) as
    I described above.
    and every tour is a different story.
    then we leave to the user the choice to aggregate the tours.
    A very minimal and not complete implementation may be also the portlet we
    already have. or not?
    we could also disable the tours that cannot be run in a certain state (eg.
    you cannot create a page if you don't have the /myfolder, or cannot create
    anything before logging in)
    
    
    >
    > I think you can add a common step to all tours with describe how the user
    > have to login if he's not authenticated. I suppose this is what you want to
    > do, right?
    >
    
    imho, it should be a single tour and the others should be available only if
    you are logged in.
    
    this is just my opinion, I don't want to persuade you :)
    
    bye
    
    massimo
    ---
    
    
    • Re: Hide step if condition callable returns False

      from vincentfretin on Aug 24, 2009 07:47 AM
      On Mon, Aug 24, 2009 at 1:22 PM, Massimo Azzolini <
      massimo.azzolini@...> wrote:
      
      > Hi
      >
      > On Sat, Aug 22, 2009 at 3:55 PM, Vincent Fretin <vincent.fretin@...>wrote:
      >
      >> Hi,
      >>
      >> Nice work guys.
      >>
      >> Can we rename "validation" by "condition" on a Step?
      >>
      >
      > initially we called it "condition" then we moved to "validation" since we
      > thought that is not just a precondition, but in some way, is a kind of
      > validation of the step. but condition is a good choice!
      >
      >
      
      >
      > we are also thinking to evolve it in a future to something more
      > structurated. for example: the "create a page" tour cannot be startd if you
      > don't have "/myfolder" already created.
      > so, the viewlet should
      > - warning the user (and we need also a description of the "problem"),
      > - put the steps in a disabled mode
      > - propose to him the tour(s) that he should complete before continuing (for
      > now I would just tell to the user to re-run the tour).
      >
      
      Look at tour2, you have a different first step if myfolder is created or
      not. What do you think?
      Or maybe we can instead set a callable to validation and the callable return
      None if all is okay, else, we return
      an error message and we include it as a error box. Maybe we should disable
      all '>>' links and the next button if you have an error. So the user only
      have the choice to click on the exit button.
      
      
      >
      >
      >
      >> On a step, when the isVisible method return false, we should hide entirely
      >> the step instead of include a warning box, no?
      >>
      >
      > sure. we just went out of time :)
      >
      >
      >>
      >> What I want to do is for example
      >> add to tour2 all the tour1 steps and when you execute the tour2 and the
      >> folder is created then you only get the tour2 steps.
      >> If the folder is not created, then you get all the steps for tour1 and
      >> tour2.
      >>
      >
      > I didn't think to tour's aggregation in that way, but it's an option.
      >
      I changed my mind. I think it's complicated to do that kind of aggregation.
      Let's keep it simple.
      
      
      >
      >
      > imho, we have two different target and so two different ways to do things.
      > if we think to complete the PLIP, we want to create tours for Plone then we
      > can assume that:
      > - the instance is "just a try"
      > - the tours available ships with plone
      > - you just have a predeterminated set of paths and scenarios
      >
      > If we think to aj to "a way to create tours in plone" then we should think
      > that:
      > - given a set of tours, an power user (not a programmer) would aggregate
      > them in different ways. many paths, many scenarios
      > - more than a user can run a tour in the same moment
      > - you can develop and release your tour for your product or internal to
      > your organization.
      >
      > Actually, I would stay in the middle: keep things as simple as possible,
      > but think in advance to possible scenarios and try to avoid refactoring.
      >
      > in my idea, every step in a tour should have a validation (or condition) as
      > I described above.
      > and every tour is a different story.
      > then we leave to the user the choice to aggregate the tours.
      > A very minimal and not complete implementation may be also the portlet we
      > already have. or not?
      > we could also disable the tours that cannot be run in a certain state (eg.
      > you cannot create a page if you don't have the /myfolder, or cannot create
      > anything before logging in)
      >
      >
      >>
      >> I think you can add a common step to all tours with describe how the user
      >> have to login if he's not authenticated. I suppose this is what you want to
      >> do, right?
      >>
      >
      > imho, it should be a single tour and the others should be available only if
      > you are logged in.
      >
      > this is just my opinion, I don't want to persuade you :)
      
      It's ok for me.
      We should include a available property on a tour, just like portlet and the
      tour is available only if it return True. The tours vocabulary takes care of
      calling the available attribute of each tour.
      For almost all the tours, we use
      available=isAuthenticatedUser
      
      and only for the login tour,
      available=isNotAuthenticatedUser
      
      And another idea for the future, it's possible to list tours available only
      a given context, say the News folder for example. Only the tours vocabulary
      need to but changed to check the context and eventually a for_ attribute on
      a Tour.
      
      
      • Re: Hide step if condition callable returns False

        from massimo on Aug 24, 2009 12:06 PM
        On Mon, Aug 24, 2009 at 1:46 PM, Vincent Fretin <vincent.fretin@...>wrote:
        
        > On Mon, Aug 24, 2009 at 1:22 PM, Massimo Azzolini <
        > massimo.azzolini@...> wrote:
        >
        >> Hi
        >>
        >> On Sat, Aug 22, 2009 at 3:55 PM, Vincent Fretin <vincent.fretin@...
        >> > wrote:
        >>
        >>> Hi,
        >>>
        >>> Nice work guys.
        >>>
        >>> Can we rename "validation" by "condition" on a Step?
        >>>
        >>
        >> initially we called it "condition" then we moved to "validation" since we
        >> thought that is not just a precondition, but in some way, is a kind of
        >> validation of the step. but condition is a good choice!
        >>
        >>
        >
        >>
        >> we are also thinking to evolve it in a future to something more
        >> structurated. for example: the "create a page" tour cannot be startd if you
        >> don't have "/myfolder" already created.
        >> so, the viewlet should
        >> - warning the user (and we need also a description of the "problem"),
        >> - put the steps in a disabled mode
        >> - propose to him the tour(s) that he should complete before continuing
        >> (for now I would just tell to the user to re-run the tour).
        >>
        >
        > Look at tour2, you have a different first step if myfolder is created or
        > not. What do you think?
        > Or maybe we can instead set a callable to validation and the callable
        > return None if all is okay, else, we return
        > an error message and we include it as a error box. Maybe we should disable
        > all '>>' links and the next button if you have an error. So the user only
        > have the choice to click on the exit button.
        >
        >
        
        at a first sight, it seems to me that the second option is simpler to
        manage.
        I supposed that in tour2 if we insert also the anon/auth option we were
        starting to manage branches.
        But at the end, we'll had to manage them in any way.
        in the way you implemented it seems more flexible to me.
        
        And maybe the validation should be a list of validator.
        
        
        >> this is just my opinion, I don't want to persuade you :)
        >
        > It's ok for me.
        > We should include a available property on a tour, just like portlet and the
        > tour is available only if it return True. The tours vocabulary takes care of
        > calling the available attribute of each tour.
        > For almost all the tours, we use
        > available=isAuthenticatedUser
        >
        > and only for the login tour,
        > available=isNotAuthenticatedUser
        >
        >
        
        sorry, but I don't catch the difference between validator and available.
        for example if we apply it to tour2 as you refactored right now?
        
        
        > And another idea for the future, it's possible to list tours available only
        > a given context, say the News folder for example. Only the tours vocabulary
        > need to but changed to check the context and eventually a for_ attribute on
        > a Tour.
        >
        
        I like it!
        
        bye
        
        massimo
        ---
        
        
        • Re: Hide step if condition callable returns False

          from vincentfretin on Aug 24, 2009 03:42 PM
          On Mon, Aug 24, 2009 at 6:06 PM, Massimo Azzolini <
          massimo.azzolini@...> wrote:
          
          >
          >
          > On Mon, Aug 24, 2009 at 1:46 PM, Vincent Fretin <vincent.fretin@...>wrote:
          >
          >> On Mon, Aug 24, 2009 at 1:22 PM, Massimo Azzolini <
          >> massimo.azzolini@...> wrote:
          >>
          >>> Hi
          >>>
          >>> On Sat, Aug 22, 2009 at 3:55 PM, Vincent Fretin <
          >>> vincent.fretin@...> wrote:
          >>>
          >>>> Hi,
          >>>>
          >>>> Nice work guys.
          >>>>
          >>>> Can we rename "validation" by "condition" on a Step?
          >>>>
          >>>
          >>> initially we called it "condition" then we moved to "validation" since we
          >>> thought that is not just a precondition, but in some way, is a kind of
          >>> validation of the step. but condition is a good choice!
          >>>
          >>>
          >>
          >>>
          >>> we are also thinking to evolve it in a future to something more
          >>> structurated. for example: the "create a page" tour cannot be startd if you
          >>> don't have "/myfolder" already created.
          >>> so, the viewlet should
          >>> - warning the user (and we need also a description of the "problem"),
          >>> - put the steps in a disabled mode
          >>> - propose to him the tour(s) that he should complete before continuing
          >>> (for now I would just tell to the user to re-run the tour).
          >>>
          >>
          >> Look at tour2, you have a different first step if myfolder is created or
          >> not. What do you think?
          >> Or maybe we can instead set a callable to validation and the callable
          >> return None if all is okay, else, we return
          >> an error message and we include it as a error box. Maybe we should disable
          >> all '>>' links and the next button if you have an error. So the user only
          >> have the choice to click on the exit button.
          >>
          >>
          >
          > at a first sight, it seems to me that the second option is simpler to
          > manage.
          > I supposed that in tour2 if we insert also the anon/auth option we were
          > starting to manage branches.
          > But at the end, we'll had to manage them in any way.
          > in the way you implemented it seems more flexible to me.
          >
          > And maybe the validation should be a list of validator.
          >
          
          I think a validation list is more flexible then what I implemented.
          
          
          >
          >
          >
          >>> this is just my opinion, I don't want to persuade you :)
          >>
          >>  It's ok for me.
          >> We should include a available property on a tour, just like portlet and
          >> the tour is available only if it return True. The tours vocabulary takes
          >> care of calling the available attribute of each tour.
          >> For almost all the tours, we use
          >> available=isAuthenticatedUser
          >>
          >> and only for the login tour,
          >> available=isNotAuthenticatedUser
          >>
          >>
          >
          > sorry, but I don't catch the difference between validator and available.
          >
          
          I think we don't need an available property after all.
          Actually in the portlet I want to color in grey the links for tours you
          can't start. How do we know that? We look at the validation list of the
          first step, if the list is not empty (it's a list of zope.i18n.Message
          error), then the link is grey, but still clickable. If you click on the link
          to start the tour, then you will see a list of warning box telling you what
          you have to do to unlock this tour.
          I'll start implementing this right now.
          
          
          • Re: Hide step if condition callable returns False

            from vincentfretin on Aug 24, 2009 05:33 PM
            On Mon, Aug 24, 2009 at 9:41 PM, Vincent Fretin <vincent.fretin@...>wrote:
            >
            >
            > I think we don't need an available property after all.
            > Actually in the portlet I want to color in grey the links for tours you
            > can't start. How do we know that? We look at the validation list of the
            > first step, if the list is not empty (it's a list of zope.i18n.Message
            > error), then the link is grey, but still clickable. If you click on the link
            > to start the tour, then you will see a list of warning box telling you what
            > you have to do to unlock this tour.
            > I'll start implementing this right now.
            >
            > I renamed validation to validators and isVisible to validate. validate have
            two parameters context and request.
            You have a warning box for each validation error message and the doStep
            links are disabled if there are errors.
            I'm satisfied with the solution. It's much simplier that my previous
            implementation.