roadmap

Forwarded conversation
Subject: Re: [drupal.org] Discussion on Btips and jquery
------------------------

Date: 2010/2/5

Hello,

I'm not sure that a generalized jquery manager would be feasible in the way that you describe. It seems to me that jquery plugins do too many different things and in many different ways. (Although, as you pointed out there are some commonalities.) I think that graphical managers for jquery plugins are better if they can be built on a plugin by plugin basis. This allows great flexibility in hooking into the different options for each plugin.

I was thinking of putting an api into beautytips that makes it easy to grab a predefined beautytips popup style and adding it to the page. It seems like this would be a good place for your manager to hook into the beautytips module. Although, I haven't actually done it yet. Anyway, when you get your module coded out, then let me know, so we can look into merging it together.

Thanks,
Matt

On Fri, Feb 5, 2010 at 1:23 AM, wrote:
kleinmp,

rsvelko (http://drupal.org/user/337401) has sent you a message via your contact form (http://drupal.org/user/390447/contact) at drupal.org.

If you don't want to receive such e-mails, you can change your settings at http://drupal.org/user/390447.

Message:

Hi,

I saw you "love" the idea of a btips_advanced module! Nice!

I was wondering sth :

- the module I propose there in the question-issue - can it be generalised for all kinds of jquery plugin implementations

I am learning jquery basics currently (not needed for the btips advanced module ..) and if I understand correctly pretty much all jquery plugins have a similar way to "hook" into the site: a css-selector and some options...

I mean can it become a "jQuery generic helper"? Do you understand my generalisation idea? It is for all those men that include the jquery implementation in blocks / tpl / .module files...

Other than that a btips manager is a crystally clear fixed plan in my head. I just need to sit and code it these days...

----------
Date: 2010/2/5
To: Matthew

Ya, I guess for generalisation to occur we have to first solve the specific use cases.. It will come by itself later (if at all).

As for the styles - there need to be a separate manager for styles and btips instances. This makes 2 managers which are basically two menu items "Btips instances" and "Btips Styles" with a list and add button and an edit link next to each btip item / style item.

The btips jquery API array can be separated to two semantic parts - visual(theme, css ...) and functional(where it hooks and what text it fetches/displays)

And the natural way of defining a btip is to 1st create the functional part and choose a style for it (some default styles + style editor/ cloner/adder )

this is the outline in my head.

I am going to draft those two CRUD UIs and the output from them will be a full btip jquery array - as per the btips README.

Your work is to tell me what to do with this array - surely I have to use the btips API function - but from within what context? hook_init? Sth like

hook_init() {

foreach( result from the DB query fetching from the btips_instances table AS btip_instance_array) {btips_API_func($btip_instance_arra) }

...
}

Agree?

Later on we can granularize this so the btips js / css is present only on pages where it is needed... I am not sure how much we can optimize this...

This seems like pretty much everything there is. (:)) like great physics professors were saying 150 yrs ago :))

Inline comments are welcome.

2010/2/5 Matthew

--

----------
Date: 2010/2/12

Yeah, i think this all makes sense, and hook_init seems to be the best way to go. Otherwise, there are too many possible combinations of pages where the beautytips would need to be added. I don't see any reasonable way of optimizing this.

I really like the idea of being able to create different custom styles and then apply those styles to specific beautytips instances. The way you've broken these out into separate managers seems logical and user-friendly.

-Matt

----------
Date: 2010/2/13
To: Matthew

(clarification)
under instances I understand 2 types of instances:
- simple one time static ones - they hook only in one place and display some manually written text
- wildcard instances - example - hooks on the .description css class everywhere and displays the description text (which can be hidden via css or parsing/overriding the html is some unknown to me way)

I clarify cause one can by mistake call an instance each separate occurance of the second type of btips instances .

Ideally we should coin/borrow some slang/terminology for that.

Suggestions?

One anaology would be:
Btips are like people - they wear clothes( styles). They live in tribes/families/groups (instance/definition above) and every tribe has members (some tribes have 1 member).

---- 2nd variant
btips rules (simple rules (1 occurence), dynamic (>1 occurence ) ) and btips occurence

Is there some standard jquery way of wording this scenario? Many jquery plugins do stuff like that...

2010/2/12 Matthew

----------
Date: 2010/2/19

I see beautytips being broken up into 3 different components:

1. style (as you described)
2. trigger selector (what css selector on the page actually triggers the beautytip)
3. content (what content displays inside the beautytip. This can be static text, or be some sort of wildcard as you mentioned)

So, I would use 'style', 'trigger', and 'content' to describe the different components to make a beautytip. Style, trigger, selector, and content are all pretty standard jquery terminology, but not specifically for this scenario.

I don't think that we need to worry too much about breaking the instances up into one occurrence, and multiple occurrences. The plugin is setup to attach the beautytip to all occurences of the trigger selector. So, if someone wants it to only appear on one of them, then they need to be more specific with their selector.

-Matt