phpwebsite-developers

[Phpwebsite-developers] Rules idea

[Shaun M. <sh...@ae...>]

This is an idea that's been kicking about my head for a while so I 
thought I'd let it out there.

Currently, some modules allow you to display a block, menu or other 
element if another module is on the screen. eg. you can display a menu 
with just the linkman module or a block only with announcements.

Some others, allow you to display an element depending on a pagemaster 
page - see phpwsRSSFeeds and kCart.

There are hacks from users to display blocks, menus etc depending on 
the category, if the user is an admin and other kinds of permission 
levels.

These are mostly hacked on afterwards and the interface is often 
different and confusing and mixing all the possible conditions in one 
interface isn't always simple. In an effort to homogenise these all 
into one interface, and perhaps this will fit in with v1.0.0 
permissions too,  I thought perhaps we could use a rule based method. 
The inspiration was Apple's Mail filtering rules for those familiar 
with the idea.

Here's a non-functioning mockup in html

http://www.aegisdesign.co.uk/examples/rules/

To explain,

This would be displayed instead of the 'Allow View' option in 
blockmaker for example. You click 'enable rules' to switch on the rules 
otherwise the default is to always display the element. You can add or 
remove rules using the -/+ buttons allowing quite a complex set. I've 
added some examples for common things you'd maybe filter on. The 
multi-select lists have to be generated when the user changes the 
filter type - eg. if they select category, it fills the list with 
categories, if they select pages, it fills with pagemaster pages.

That's the idea. I can see a couple of problems with it already but 
maybe they can be overcome.

1) selecting a user from a list of a couple of thousand is not viable - 
see the Notes module for how that was addressed.

2) you might want to filter on a text field - eg. pagemaster page where 
title begins with/contains 'some text'


For the core, I'd guess this is some part of layout in that it would 
keep a list of elements and if they were rule enabled or not. Or 
perhaps this is useful at a module level so that individual content is 
rule based also. A table somewhere else stores the rules.

For the module developer, it'd be as simple to add in rules editing to 
their module as they can with fatcat now.


Thoughts anyone?


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Rules idea

[Wendall C. <wen...@to...>]

Shaun,

This is a great idea. I can code the concept into phpwsRSSFeeds for now
as a demo. I agree that there needs to be methods for doing this
consistently across the board. I think the way it is done should be
planned and not an afterthought for certain. Maybe we could create a
register table for item placement. So there is just one query to the
database per page view to determine placement of items for all modules.

Wendall

On Thu, 2004-12-02 at 04:16 +0000, Shaun Murray wrote:
> This is an idea that's been kicking about my head for a while so I 
> thought I'd let it out there.
> 
> Currently, some modules allow you to display a block, menu or other 
> element if another module is on the screen. eg. you can display a menu 
> with just the linkman module or a block only with announcements.
> 
> Some others, allow you to display an element depending on a pagemaster 
> page - see phpwsRSSFeeds and kCart.
> 
> There are hacks from users to display blocks, menus etc depending on 
> the category, if the user is an admin and other kinds of permission 
> levels.
> 
> These are mostly hacked on afterwards and the interface is often 
> different and confusing and mixing all the possible conditions in one 
> interface isn't always simple. In an effort to homogenise these all 
> into one interface, and perhaps this will fit in with v1.0.0 
> permissions too,  I thought perhaps we could use a rule based method. 
> The inspiration was Apple's Mail filtering rules for those familiar 
> with the idea.
> 
> Here's a non-functioning mockup in html
> 
> http://www.aegisdesign.co.uk/examples/rules/
> 
> To explain,
> 
> This would be displayed instead of the 'Allow View' option in 
> blockmaker for example. You click 'enable rules' to switch on the rules 
> otherwise the default is to always display the element. You can add or 
> remove rules using the -/+ buttons allowing quite a complex set. I've 
> added some examples for common things you'd maybe filter on. The 
> multi-select lists have to be generated when the user changes the 
> filter type - eg. if they select category, it fills the list with 
> categories, if they select pages, it fills with pagemaster pages.
> 
> That's the idea. I can see a couple of problems with it already but 
> maybe they can be overcome.
> 
> 1) selecting a user from a list of a couple of thousand is not viable - 
> see the Notes module for how that was addressed.
> 
> 2) you might want to filter on a text field - eg. pagemaster page where 
> title begins with/contains 'some text'
> 
> 
> For the core, I'd guess this is some part of layout in that it would 
> keep a list of elements and if they were rule enabled or not. Or 
> perhaps this is useful at a module level so that individual content is 
> rule based also. A table somewhere else stores the rules.
> 
> For the module developer, it'd be as simple to add in rules editing to 
> their module as they can with fatcat now.
> 
> 
> Thoughts anyone?
> 
> 
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Rules idea

[Wendall C. <wen...@to...>]

One other item I wanted to discuss is category. I haven't added category
placement for on major reason. 

What do I base the category from? The Web Pages item? The Article
Manager Article? If any item on the page is in that category? I'm
assuming you mean if any item on the page is in that category. I just
don't know how realistic this would be to do though without a lot of
thought going into the design. Unless it is done properly, the amount of
database queries to check categories would be insane. It's almost a
catch-22. The list of categories for every item sent to layout would
need to be available before the items were generated for layout on the
page. I'm not certain how you'd achieve this effectively. My current
method checks the current module in the $_REQUEST var against each items
setting. It does the same for webpages. Checks the $_REQUEST var to see
if a page has been requested and generates a block or body element. This
is a very weak method. It would be much stronger if, as I think Shawn is
suggesting. There was a table or set of tables for Layout to check for
advanced layout and automagically fetched the items from all mods. This
could even further reduce the impact of inc/runtime.php to mostly be
used for module administrative tasks, lists and item views. As it is,
there could be a ton of overhead processing each inc/runtime.php if they
are all banging against the database to retrieve settings for dynamic
placement.

Wendall

On Thu, 2004-12-02 at 08:38 -0800, Wendall Cada wrote:
> Shaun,
> 
> This is a great idea. I can code the concept into phpwsRSSFeeds for now
> as a demo. I agree that there needs to be methods for doing this
> consistently across the board. I think the way it is done should be
> planned and not an afterthought for certain. Maybe we could create a
> register table for item placement. So there is just one query to the
> database per page view to determine placement of items for all modules.
> 
> Wendall
> 
> On Thu, 2004-12-02 at 04:16 +0000, Shaun Murray wrote:
> > This is an idea that's been kicking about my head for a while so I 
> > thought I'd let it out there.
> > 
> > Currently, some modules allow you to display a block, menu or other 
> > element if another module is on the screen. eg. you can display a menu 
> > with just the linkman module or a block only with announcements.
> > 
> > Some others, allow you to display an element depending on a pagemaster 
> > page - see phpwsRSSFeeds and kCart.
> > 
> > There are hacks from users to display blocks, menus etc depending on 
> > the category, if the user is an admin and other kinds of permission 
> > levels.
> > 
> > These are mostly hacked on afterwards and the interface is often 
> > different and confusing and mixing all the possible conditions in one 
> > interface isn't always simple. In an effort to homogenise these all 
> > into one interface, and perhaps this will fit in with v1.0.0 
> > permissions too,  I thought perhaps we could use a rule based method. 
> > The inspiration was Apple's Mail filtering rules for those familiar 
> > with the idea.
> > 
> > Here's a non-functioning mockup in html
> > 
> > http://www.aegisdesign.co.uk/examples/rules/
> > 
> > To explain,
> > 
> > This would be displayed instead of the 'Allow View' option in 
> > blockmaker for example. You click 'enable rules' to switch on the rules 
> > otherwise the default is to always display the element. You can add or 
> > remove rules using the -/+ buttons allowing quite a complex set. I've 
> > added some examples for common things you'd maybe filter on. The 
> > multi-select lists have to be generated when the user changes the 
> > filter type - eg. if they select category, it fills the list with 
> > categories, if they select pages, it fills with pagemaster pages.
> > 
> > That's the idea. I can see a couple of problems with it already but 
> > maybe they can be overcome.
> > 
> > 1) selecting a user from a list of a couple of thousand is not viable - 
> > see the Notes module for how that was addressed.
> > 
> > 2) you might want to filter on a text field - eg. pagemaster page where 
> > title begins with/contains 'some text'
> > 
> > 
> > For the core, I'd guess this is some part of layout in that it would 
> > keep a list of elements and if they were rule enabled or not. Or 
> > perhaps this is useful at a module level so that individual content is 
> > rule based also. A table somewhere else stores the rules.
> > 
> > For the module developer, it'd be as simple to add in rules editing to 
> > their module as they can with fatcat now.
> > 
> > 
> > Thoughts anyone?
> > 
> > 
> > Shaun
> > aegis design - http://www.aegisdesign.co.uk
> > 
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now. 
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > Phpwebsite-developers mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Rules idea

[Shaun M. <sh...@ae...>]

On 2 Dec 2004, at 16:38, Wendall Cada wrote:

> Shaun,
>
> This is a great idea. I can code the concept into phpwsRSSFeeds for now
> as a demo.

That would be cool.

> I agree that there needs to be methods for doing this
> consistently across the board. I think the way it is done should be
> planned and not an afterthought for certain. Maybe we could create a
> register table for item placement. So there is just one query to the
> database per page view to determine placement of items for all modules.
>

Yeah, I'd much rather something was done across the board in such a way 
that it's flexible enough for the future but if we can get it going as 
a prototype at least we know what the pitfalls will be.


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Rules idea

[Shaun M. <sh...@ae...>]

On 2 Dec 2004, at 17:12, Wendall Cada wrote:

> One other item I wanted to discuss is category. I haven't added  
> category
> placement for on major reason.
>
> What do I base the category from? The Web Pages item? The Article
> Manager Article? If any item on the page is in that category? I'm
> assuming you mean if any item on the page is in that category.

That's a good point. Since you can have multiple categories on the page  
that could be a nightmare. I'm not sure how the current category hacks  
work exactly. See  
http://www.phpwebsitemanual.com/index.php? 
module=announce&ANN_user_op=view&ANN_id=181 for the menuman hack. I've  
not used it myself as it interfered with my pagemaster menu hack. ;-)


> I just
> don't know how realistic this would be to do though without a lot of
> thought going into the design. Unless it is done properly, the amount  
> of
> database queries to check categories would be insane. It's almost a
> catch-22. The list of categories for every item sent to layout would
> need to be available before the items were generated for layout on the
> page. I'm not certain how you'd achieve this effectively. My current
> method checks the current module in the $_REQUEST var against each  
> items
> setting. It does the same for webpages. Checks the $_REQUEST var to see
> if a page has been requested and generates a block or body element.  
> This
> is a very weak method. It would be much stronger if, as I think Shawn  
> is
> suggesting. There was a table or set of tables for Layout to check for
> advanced layout and automagically fetched the items from all mods. This
> could even further reduce the impact of inc/runtime.php to mostly be
> used for module administrative tasks, lists and item views. As it is,
> there could be a ton of overhead processing each inc/runtime.php if  
> they
> are all banging against the database to retrieve settings for dynamic
> placement.
>

Yep, I alluded to it being part of layout in the first post but then  
thought it might be useful at a finer grained level than at a block  
level.

One thought I had was that when you've got the layout panel switched  
on, as well as being able to change the box style and position, you'd  
be able to change the rules for that block directly in situ if it was  
entirely at the layout level. That'd be nice and easy to visually  
modify the sites rules rather than from inside each modules admin page.


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Rules idea

[Wendall C. <wen...@to...>]

On Thu, 2004-12-02 at 17:34 +0000, Shaun Murray wrote:
> One thought I had was that when you've got the layout panel switched  
> on, as well as being able to change the box style and position, you'd  
> be able to change the rules for that block directly in situ if it was  
> entirely at the layout level. That'd be nice and easy to visually  
> modify the sites rules rather than from inside each modules admin page.

A Layout lib to handle creating the settings would be great. The
settings would be more like how setting categories with fatcat within a
module are now. This would save a ton of coding on the module author's
part and give a standard method for placement. I really like the idea of
being able to change placement by editing the item or straight from
layout.

Wendall

Re: [Phpwebsite-developers] Rules idea

[Matthew M. <ma...@tu...>]

Sorry to get back so late on this.

I am still rolling this idea around in my head. What Steven and I had
come up with was a block module that allowed you to put the block where
ever you want. So they could go inside announcements, pages, etc. as
well as on the side of a page.

I think this system would fit well as one of the ways to decide where a
block appears. We can get into it more when I get started on that
module.

Matt

On Wed, 2004-12-01 at 23:16, Shaun Murray wrote:
> This is an idea that's been kicking about my head for a while so I 
> thought I'd let it out there.
> 
> Currently, some modules allow you to display a block, menu or other 
> element if another module is on the screen. eg. you can display a menu 
> with just the linkman module or a block only with announcements.
> 
> Some others, allow you to display an element depending on a pagemaster 
> page - see phpwsRSSFeeds and kCart.
> 
> There are hacks from users to display blocks, menus etc depending on 
> the category, if the user is an admin and other kinds of permission 
> levels.
> 
> These are mostly hacked on afterwards and the interface is often 
> different and confusing and mixing all the possible conditions in one 
> interface isn't always simple. In an effort to homogenise these all 
> into one interface, and perhaps this will fit in with v1.0.0 
> permissions too,  I thought perhaps we could use a rule based method. 
> The inspiration was Apple's Mail filtering rules for those familiar 
> with the idea.
> 
> Here's a non-functioning mockup in html
> 
> http://www.aegisdesign.co.uk/examples/rules/
> 
> To explain,
> 
> This would be displayed instead of the 'Allow View' option in 
> blockmaker for example. You click 'enable rules' to switch on the rules 
> otherwise the default is to always display the element. You can add or 
> remove rules using the -/+ buttons allowing quite a complex set. I've 
> added some examples for common things you'd maybe filter on. The 
> multi-select lists have to be generated when the user changes the 
> filter type - eg. if they select category, it fills the list with 
> categories, if they select pages, it fills with pagemaster pages.
> 
> That's the idea. I can see a couple of problems with it already but 
> maybe they can be overcome.
> 
> 1) selecting a user from a list of a couple of thousand is not viable - 
> see the Notes module for how that was addressed.
> 
> 2) you might want to filter on a text field - eg. pagemaster page where 
> title begins with/contains 'some text'
> 
> 
> For the core, I'd guess this is some part of layout in that it would 
> keep a list of elements and if they were rule enabled or not. Or 
> perhaps this is useful at a module level so that individual content is 
> rule based also. A table somewhere else stores the rules.
> 
> For the module developer, it'd be as simple to add in rules editing to 
> their module as they can with fatcat now.
> 
> 
> Thoughts anyone?
> 
> 
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

Re: [Phpwebsite-developers] Rules idea

[Shaun M. <sh...@ae...>]

On 3 Dec 2004, at 13:12, Matthew McNaney wrote:

> Sorry to get back so late on this.
>
> I am still rolling this idea around in my head. What Steven and I had
> come up with was a block module that allowed you to put the block where
> ever you want. So they could go inside announcements, pages, etc. as
> well as on the side of a page.
>
> I think this system would fit well as one of the ways to decide where a
> block appears. We can get into it more when I get started on that
> module.
>

It's more like it's an extra piece in deciding 'why' something is 
displayed, not just 'where' so I think it'd match up even if you can 
display blocks inside pages - which would be damned useful btw. The 
idea is to be wider than just a block module so that anything with a 
content variable is able to be told 'why' it should display.

Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Rules idea

[Ryan R. <to...@gm...>]

+1  on this one.   Something we've been looking at for awhile.  I like
this approach as well.

Ryan Roland

Indiana University

On Thu, 2 Dec 2004 04:16:36 +0000, Shaun Murray <sh...@ae...> wrote:
> This is an idea that's been kicking about my head for a while so I
> thought I'd let it out there.
> 
> Currently, some modules allow you to display a block, menu or other
> element if another module is on the screen. eg. you can display a menu
> with just the linkman module or a block only with announcements.
> 
> Some others, allow you to display an element depending on a pagemaster
> page - see phpwsRSSFeeds and kCart.
> 
> There are hacks from users to display blocks, menus etc depending on
> the category, if the user is an admin and other kinds of permission
> levels.
> 
> These are mostly hacked on afterwards and the interface is often
> different and confusing and mixing all the possible conditions in one
> interface isn't always simple. In an effort to homogenise these all
> into one interface, and perhaps this will fit in with v1.0.0
> permissions too,  I thought perhaps we could use a rule based method.
> The inspiration was Apple's Mail filtering rules for those familiar
> with the idea.
> 
> Here's a non-functioning mockup in html
> 
> http://www.aegisdesign.co.uk/examples/rules/
> 
> To explain,
> 
> This would be displayed instead of the 'Allow View' option in
> blockmaker for example. You click 'enable rules' to switch on the rules
> otherwise the default is to always display the element. You can add or
> remove rules using the -/+ buttons allowing quite a complex set. I've
> added some examples for common things you'd maybe filter on. The
> multi-select lists have to be generated when the user changes the
> filter type - eg. if they select category, it fills the list with
> categories, if they select pages, it fills with pagemaster pages.
> 
> That's the idea. I can see a couple of problems with it already but
> maybe they can be overcome.
> 
> 1) selecting a user from a list of a couple of thousand is not viable -
> see the Notes module for how that was addressed.
> 
> 2) you might want to filter on a text field - eg. pagemaster page where
> title begins with/contains 'some text'
> 
> For the core, I'd guess this is some part of layout in that it would
> keep a list of elements and if they were rule enabled or not. Or
> perhaps this is useful at a module level so that individual content is
> rule based also. A table somewhere else stores the rules.
> 
> For the module developer, it'd be as simple to add in rules editing to
> their module as they can with fatcat now.
> 
> Thoughts anyone?
> 
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>