Menu
▾
▴
Re: [Tiki-devel] Features get the ability to have a profile as a dependency
|
From: gezzzan <ge...@ya...> - 2012-08-06 13:53:25
|
Hi
having a sysName field in the tiki_trackers table would help development and the code easier to understand. Same as for permission and feature names, a tracker sysName must be unique, so you can build logic around it, reference on it and move/syncronise tracker data between systems/deployments much easier.
ps: the concept is there for tracker fields, it is called permName, which stands for permanent name, but it is not a good naming, it can be confused with permission. sysName (system Name) is a better naming convention imho. Anyway, having system names is a useful thing, I bet soon it will be there in categories, structures, groups and some other core tables too.
cheers,
gezza
________________________________
From: Robert Plummer <rob...@gm...>
To: Xavier de Pedro <xav...@vh...>
Cc: Marc Laporte <ma...@ma...>; Tiki developers <tik...@li...>
Sent: Monday, August 6, 2012 3:28 PM
Subject: Re: [Tiki-devel] Features get the ability to have a profile as a dependency
It is no problem Xavi. The issue you are running into is that to aid in development we've used the tracker by name. So this doesn't have to do with profiles at all but rather tracker query. Tracker query needs the perm name, just has not been something I've gotten around to, but will be easy to integrate.
On Mon, Aug 6, 2012 at 8:58 AM, Xavier de Pedro <xav...@vh...> wrote:
Dear Robert:
>
>I had to rename the tracker, since the name was not applicable in
our production site (we have other trackers in production since a
year ago to track time invested in projects, etc, and the former
name was missleading to our colleagues regarding the other
trackers).
>
>With most profiles, this is not an issue, since once the profile is
applied, the user can rename text strings, descriptions, etc. as if
they were created normally within tiki.
>
>Moreover, when I hit at "commit items to the timesheet" (or similar;
I have the interface in another language), they don't get saved, but
show up as zeros (in the column time invested, and column summary is
blank, description is blank; username is ok). I recall trying with
everything in English (to avoid potential source of issues due to
i18n, but same effect)
>
>Sorry I can't invest more time on this right now.
>
>Xavi
>
>
>
>On 06/08/12 14:13, Robert Plummer wrote:
>
>Xavi,
>>Can you tell me what is broken with it? Did you change the names
of the trackers? Are you sure it is broken, or was it never
implemented? Keep in mind this use case uses trackers + jquery +
jquery ui + jtrack. The only part that has to do with profiles
are trackers. Have you customized any part of timesheets and
because of those customizations something has broken? I've
checked the dev page (http://dev.tiki.org/TimeSheet) and I don't see any bugs, would you be so kind as to list them?
>>
>>Thanks Xavi.
>>
>>
>>On Mon, Aug 6, 2012 at 3:42 AM, Xavier de Pedro <xav...@vh...> wrote:
>>
>>+1, Marc (good point).
>>>
>>>The added feature provided by the Timesheet profile is
currently broken
>>>(at least for me) in 9x production sites since before 9.0
(beyond simple
>>>use cases at demo.t.o). And since it seems too fragile for me,
and my
>>>money is very limited, I didn't plan to base any site on the
usage on it
>>>(and I can't afford more of my limited time as a project
manager either
>>>with it).
>>>
>>>+1 for robust ("resilient") features. And this type of
features (based
>>>on profiles) doesn't look like such, according to my own
experience.
>>>
>>>Xavi
>>>
>>>
>>>On 05/08/12 16:39, Marc Laporte wrote:
>>>> Hi!
>>>>
>>>> One thing that worries me about features depending on
profiles is upgradability.
>>>>
>>>> If tiki-timesheet.php has data in standard MySQL
tables like all the
>>>> other features, we know what to expect and the
feature can evolve via:
>>>> http://dev.tiki.org/Database+Schema+Upgrade
>>>>
>>>> If time sheets are profiles, will we have profiles to
upgrade from one
>>>> version to another? Seems tricky to keep data in sync
with added
>>>> functionality.
>>>>
>>>> So profiles are more for combining features for use
cases. For new
>>>> features, I get the feeling that trying to use
trackers for storing
>>>> data just adds an abstraction layer, and complexity.
>>>>
>>>> I like the idea of attributes for adding additional
meta-data to an
>>>> object though. So say timesheets have 7 basic fields
in MySQL, there
>>>> could be an attibute to add some user-defined ones.
>>>>
>>>> A topic for a webinar I guess :-)
>>>>
>>>> Best regards,
>>>>
>>>> M ;-)
>>>>
>>>>
>>>> On Wed, Jun 27, 2012 at 8:24 AM, Louis-Philippe
Huberdeau
>>>> <lph...@lp...> wrote:
>>>>> I don't think there is anything wrong with
depending on certain tracker
>>>>> structures. Perhaps imposing that some fields
have permNames of such and
>>>>> such in the code. Just check the structure and
report. The trackers
>>>>> themselves only have IDs at the moment, but those
can fit nicely in a
>>>>> preference.
>>>>>
>>>>> I can understand there are special cases. For
cartograf, I added a few
>>>>> custom templates where the UI needed to be more
specific than I could manage
>>>>> otherwise late in the project. However, the
features should be developed
>>>>> with being open in mind. Profiles are great when
assembling those features
>>>>> get complicated. However, asking a profile to be
installed to use a feature
>>>>> seems backward.
>>>>>
>>>>> As I mentioned, suggesting is good. From the
feature, pointing to a list of
>>>>> profiles that use it, either as examples or full
solutions, makes a lot more
>>>>> sense.
>>>>>
>>>>> There is a delicate balance to keep. I have found
that exposing more as
>>>>> re-usable services, callable through javascript,
gives plenty of
>>>>> flexibility.
>>>>>
>>>>> --
>>>>> LP
>>>>>
>>>>>
>>>>> On Wed, Jun 27, 2012 at 8:06 AM, Torsten
Fabricius <to...@fa...>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> my concernes are following:
>>>>>>
>>>>>> if I have a certain profile as dependency, I
could - longterm - run into
>>>>>> the situation, that two features might depend
on two profiles, that have
>>>>>> settings which are not compatible to each
other.
>>>>>>
>>>>>> I just imagine that it could - in future of
development - make features
>>>>>> incompatible to each other and I then would
need more than one installation
>>>>>> to use both features ...
>>>>>>
>>>>>> Example:
>>>>>> Blog, Forum, Wiki and CMS might need
profiles, which are not compatible,
>>>>>> but are dependancies and thus I need an
installation for a Blog and one for
>>>>>> CMS and one for a forum ... next step would
be different software for each
>>>>>> usecase and the opposit of the idea of Tiki.
>>>>>>
>>>>>> IF I understand right, I woul give a "-1"
aswell, but perhabs I just
>>>>>> missunderstand a smart idea ....
>>>>>> Robert you say "ability to have as
dependancy" and you do not say "in
>>>>>> future features depend".
>>>>>> So might you perhabs explain a bit clearer in
respect of the direction you
>>>>>> suggest us to go and if and how the
"intracompatibility" of Tikis features
>>>>>> will be guaranteed?
>>>>>>
>>>>>> Cheers
>>>>>> --T
>>>>>>
>>>>>> Am 27.06.2012 12:43, schrieb Jonny Bradley:
>>>>>>
>>>>>> Hmmm, the more i think about this the less
i'm convinced.
>>>>>>
>>>>>> Dependencies should be on the current "state"
of Tiki, and this state can
>>>>>> be reached in several ways; clicking lots of
little checkboxes, applying a
>>>>>> profile, hacking the database, er... etc.
>>>>>>
>>>>>> Are you saying you're planning features that
depends on certain (say)
>>>>>> trackers and fields to be there? If so why
not make the dependency on the
>>>>>> actual objects you are depending on, rather
than a script/macro of one
>>>>>> particular way to create them? (which as
people have already said isn't
>>>>>> fixed and will be edited for different
versions, translated etc).
>>>>>>
>>>>>> So i'm afraid it's a -1 from me, but a +1 to
extend dependencies beyond
>>>>>> just prefs, to any tiki objects.
>>>>>>
>>>>>> My 2px,
>>>>>>
>>>>>> jonny
>>>>>>
>>>>>>
>>>>>> On 26 Jun 2012, at 19:23, Robert Plummer
wrote:
>>>>>>
>>>>>> I think some of that was left out, but the
end result (once I'm done) it
>>>>>> will be a dependency just like features. I
didn't want to go too far with
>>>>>> it in the initial commit because it does
change our thinking a bit with the
>>>>>> use of profiles and there is a possibility
that it may be rolled back.
>>>>>> One of the neat things with Tracker Query and
the use of profiles is that
>>>>>> it is somewhat like an ORM interface for
trackers, and many trackers are
>>>>>> installed with profiles. ORM's are very
useful when creating apps, they
>>>>>> speed things up. The added value from having
a tracker built into an app is
>>>>>> that it provides a bases to extend within
other parts of tiki either in
>>>>>> custom php apps or using wiki syntax and
plugins. So the big picture at
>>>>>> least within the orm model is that for adding
a dependency on a profile is
>>>>>> to give users the ability to further extend
tiki without ever learning to
>>>>>> code php/smarty/html/javascript/ajax etc. but
still holding true to the tiki
>>>>>> model (tightly integrated knowledgebase
infrastructure).
>>>>>>
>>>>>> On Tue, Jun 26, 2012 at 1:48 PM, Jean-Marc
Libs <jea...@gm...>
>>>>>> wrote:
>>>>>> I am trying to understand the big picture.
>>>>>>
>>>>>> What is a dependency ?
>>>>>> Will the feature refuse to work if the
profile is not installed ?
>>>>>> Will it just provide a link to installing the
profile?
>>>>>>
>>>>>> What if a corporate Tiki points to my own
profile site with variants of
>>>>>> the "official profiles", with different names
in another language ?
>>>>>>
>>>>>> Cheers,
>>>>>> Jyhem
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 26, 2012 at 4:45 PM, Robert
Plummer
>>>>>> <rob...@gm...> wrote:
>>>>>> Why have a hard and fast rule about something
like this? Profiles should
>>>>>> be used where we need or want them.
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 26, 2012 at 10:39 AM,
Louis-Philippe Huberdeau
>>>>>> <lph...@lp...> wrote:
>>>>>> Is it really a dependency or should it be a
suggestion?
>>>>>>
>>>>>> The way I see it, the reason why some
features depend on profiles is that
>>>>>> they were recently added and some integration
is lacking. The feature relies
>>>>>> on very specific parameters to work. Putting
a hard dependency on a profile
>>>>>> can reduce the possible uses for the feature.
>>>>>>
>>>>>> --
>>>>>> LP
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 26, 2012 at 10:36 AM, Marc
Laporte <ma...@ma...>
>>>>>> wrote:
>>>>>> I like!!
>>>>>>
>>>>>> M ;-)
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 26, 2012 at 9:57 AM, Robert
Plummer
>>>>>> <rob...@gm...> wrote:
>>>>>>
>>>>>> This is really just a UI change to notify the
admin adding features etc,
>>>>>> but
>>>>>> I've noticed that (and I've been using more
and more) profiles tightly
>>>>>> with
>>>>>> features. Some features won't even run
without a profile applied, at
>>>>>> least
>>>>>> not correctly.... which brings me to r42094.
Now we have the ability to
>>>>>> set a profile as a dependency from
lib/prefs/feature.php. This doesn't
>>>>>> have
>>>>>> a broad impact other than a notification. I
will go ahead and add the
>>>>>> wiki
>>>>>> info on this in a few but I thought I'd let
the community know.
>>>>>>
>>>>>> Example from lib/prefs/feature.php line
2542-2554:
>>>>>> {CODE()}
>>>>>> 'feature_forwardlinkprotocol' =>
array(
>>>>>> 'name' =>
tra('ForwardLink-Protocol'),
>>>>>> 'type' => 'flag',
>>>>>> 'help' =>
'ForwardLinkProtocol',
>>>>>> 'keywords' => 'forward link
forwardlink share feed',
>>>>>> 'description' => tra('A
Dynamic Compendia'),
>>>>>> 'default' => 'n',
>>>>>> 'warning' =>
tra('Experimental'),
>>>>>> 'tags' =>
array('experimental'),
>>>>>> 'dependencies' => array(
>>>>>> 'profiles' =>
array('Simple Wiki Attribute')
>>>>>> )
>>>>>> ),
>>>>>> {CODE}
>>>>>>
>>>>>> --
>>>>>> Robert Plummer
>>>>>>
>>>>>>
>>>>>>
------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways
today's security and
>>>>>> threat landscape has changed and how IT
managers can respond. Discussions
>>>>>> will include endpoint security, mobile
security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>
_______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> Tik...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>> --
>>>>>> Marc Laporte
>>>>>>
>>>>>> http://MarcLaporte.com
>>>>>> http://Tiki.org/MarcLaporte
>>>>>> http://AvanTech.net
>>>>>>
>>>>>>
>>>>>>
------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways
today's security and
>>>>>> threat landscape has changed and how IT
managers can respond. Discussions
>>>>>> will include endpoint security, mobile
security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>
_______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> Tik...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways
today's security and
>>>>>> threat landscape has changed and how IT
managers can respond. Discussions
>>>>>> will include endpoint security, mobile
security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>
_______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> Tik...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Robert Plummer
>>>>>>
>>>>>>
>>>>>>
------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways
today's security and
>>>>>> threat landscape has changed and how IT
managers can respond. Discussions
>>>>>> will include endpoint security, mobile
security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>
_______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> Tik...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways
today's security and
>>>>>> threat landscape has changed and how IT
managers can respond. Discussions
>>>>>> will include endpoint security, mobile
security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>
_______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> Tik...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Robert Plummer
>>>>>>
>>>>>>
------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways
today's security and
>>>>>> threat landscape has changed and how IT
managers can respond. Discussions
>>>>>> will include endpoint security, mobile
security and the latest in malware
>>>>>> threats.
>>>>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> Tik...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>>
------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways
today's security and
>>>>>> threat landscape has changed and how IT
managers can respond. Discussions
>>>>>> will include endpoint security, mobile
security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>
_______________________________________________
>>>>>> TikiWiki-devel mailing list
>>>>>> Tik...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Torsten Fabricius
>>>>>> fon: +49 178 8 272 383
>>>>>> to...@fa...
>>>>>> to...@ti...
>>>>>>
>>>>>>
>>>
>>>
>>>------------------------------------------------------------------------------
>>>Live Security Virtual Conference
>>>Exclusive live event will cover all the ways today's
security and
>>>threat landscape has changed and how IT managers can
respond. Discussions
>>>will include endpoint security, mobile security and the
latest in malware
>>>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>_______________________________________________
>>>TikiWiki-devel mailing list
>>>Tik...@li...
>>>https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>
>>
>>--
>>Robert Plummer
>>
>>
>>
>>------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>>_______________________________________________
TikiWiki-devel mailing list Tik...@li... https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
--
Robert Plummer
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
TikiWiki-devel mailing list
Tik...@li...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |