Menu
▾
▴
phptmapi-discuss — This is the place to discuss PHPTMAPI development and usage issues.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(18) |
Oct
(12) |
Nov
(5) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(13) |
| 2010 |
Jan
(1) |
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Johannes S. <jsc...@t8...> - 2011-09-19 21:24:00
|
Hi Andrius, PHPTMAPI is just an API, a set of interfaces enriched by some exceptions and a TopicMapSystemFactory class. So, the (IMO) correct requirements would be to provide demos how to use a) an _implementation_ of PHPTMAPI and - more general - how to use b) Topic Maps in a PHP application. To answer a): The only impl. of PHPTMAPI I know is QuaaxTM [1]. The download package contains an example.php [2] which provides a simple usage example with lots of comments. Pls. have a look at this. To answer b) (much harder): There are very different use cases for Topic Maps. I remember a short thread on the toicmapmail ML [3] which might help a bit as it is about applications. A "Topic Maps engine" [4] provides access to Topic Maps data (topic maps, topics, associations, etc.) - it's the "M" in MVC to come back to the thread mentioned above. It's up to you what you would like to model with Topic Maps - and it is also up to you what your application will "do" with Topic Maps data and/or present that data in the UI. PHPTMAPI is just an API, QuaaxTM just an implementation of PHPTMAPI, a tool to "do Topic Maps". Cheers, Johannes [1] http://quaaxtm.sourceforge.net/ [2] http://quaaxtm.svn.sourceforge.net/viewvc/quaaxtm/trunk/example.php?revision=549&view=markup [3] http://www.infoloom.com/pipermail/topicmapmail/2011q3/009157.html [4] http://www.garshol.priv.no/tmtools/category.jsp?id=topicmapsengine (currently 503 :( ) Am 19.09.2011 21:32, schrieb Andrius Lauraitis: > Great. work. What i think would be nice ( perhaps even mandatory) is > to do a demo on how to use PHPTMAPI in PHP applications. Because now > there are very few tutorials and i doubt that many people are familiar > with this product. Best regards > > 2011/9/19 Johannes Schmidt <jsc...@t8... <mailto:jsc...@t8...>> > > Hi all, > PHPTMAPI 2.1 has been released. See http://phptmapi.sourceforge.net/ > > Best regards, > Johannes > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and > makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Phptmapi-discuss mailing list > Php...@li... > <mailto:Php...@li...> > https://lists.sourceforge.net/lists/listinfo/phptmapi-discuss > > > > > -- > Pagarbiai, > > Andrius Lauraitis |
|
From: Andrius L. <a.l...@gm...> - 2011-09-19 19:32:55
|
Great. work. What i think would be nice ( perhaps even mandatory) is to do a demo on how to use PHPTMAPI in PHP applications. Because now there are very few tutorials and i doubt that many people are familiar with this product. Best regards 2011/9/19 Johannes Schmidt <jsc...@t8...> > Hi all, > PHPTMAPI 2.1 has been released. See http://phptmapi.sourceforge.net/ > > Best regards, > Johannes > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Phptmapi-discuss mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phptmapi-discuss > -- Pagarbiai, Andrius Lauraitis |
|
From: Johannes S. <jsc...@t8...> - 2011-09-19 19:18:34
|
Hi all, PHPTMAPI 2.1 has been released. See http://phptmapi.sourceforge.net/ Best regards, Johannes |
|
From: Johannes S. <jsc...@t8...> - 2011-09-19 05:43:55
|
Hi all, no objections have been raised to release version 2.1. So I will do a release within the next days. Cheers, Johannes P.S. I have deployed some CSS to http://phptmapi.sourceforge.net/ Am 15.09.2011 18:14, schrieb Johannes Schmidt: > Hi all, > I'd like to start the vote on PHPTMAPI 2.1. The changes are described in > [1]. > The proposal has been committed so SVN [2]. > > Vote for PHPTMAPI 2.1: > > [ ] +1 -- yes, release PHPTMAPI 2.1 > [ ] +- 0 -- no opinion > [ ] -1 -- it's not ready yet (why?) > > For the records: me +1 > > I'll keep the vote open until 2011-09-18. > > Best regards, > Johannes > > [1] > http://sourceforge.net/mailarchive/forum.php?thread_name=4E6F6B1E.7070308%40t8d.de&forum_name=phptmapi-discuss > [2] http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/ > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > Phptmapi-discuss mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phptmapi-discuss > |
|
From: Johannes S. <jsc...@t8...> - 2011-09-15 16:15:30
|
Hi all, I'd like to start the vote on PHPTMAPI 2.1. The changes are described in [1]. The proposal has been committed so SVN [2]. Vote for PHPTMAPI 2.1: [ ] +1 -- yes, release PHPTMAPI 2.1 [ ] +- 0 -- no opinion [ ] -1 -- it's not ready yet (why?) For the records: me +1 I'll keep the vote open until 2011-09-18. Best regards, Johannes [1] http://sourceforge.net/mailarchive/forum.php?thread_name=4E6F6B1E.7070308%40t8d.de&forum_name=phptmapi-discuss [2] http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/ |
|
From: Johannes S. <jsc...@t8...> - 2011-09-13 14:54:23
|
Hi all, I'd like to release version 2.1 which includes the following changes: - Allow any datatype for parameter $value in TopicMapSystemFactory::setProperty() (is object only) - Change code style: Add prefix "_" for private class members, set opening brackets for classes / interfaces and class / interface methods on new line - Add documentation for private class members - Introduce a changes log [1] All proposed changes have been committed to SVN [2] to enable a review. The changes are also "in use" in QuaaxTM 0.7.0 [3]. If you have any thoughts please let us know. Best regards, Johannes [1] http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/CHANGES?revision=84&view=markup [2] http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/ [3] http://quaaxtm.sourceforge.net/ |
|
From: Johannes S. <jsc...@t8...> - 2011-01-15 18:56:13
|
Hi all, version 2.0.1 has been released. See [1]. Best regards, Johannes [1] http://sourceforge.net/projects/phptmapi/files/ |
|
From: Johannes S. <jsc...@t8...> - 2011-01-15 12:52:24
|
Hi all, we have no feedback and consequently no objections to the proposal for PHPTMAPI 2.0.1. I'll prepare a release. Best regards, Johannes |
|
From: Johannes S. <jsc...@t8...> - 2011-01-09 13:56:10
|
Hi all, I'd like to start the vote on PHPTMAPI 2.0.1. The changes are described in [1] and [2]. The proposal has been committed so SVN (rev. 68) [3]. Vote for releasing PHPTMAPI 2.0.1 (SVN rev. 68): [ ] +1 -- yes, release PHPTMAPI 2.0.1 [ ] +- 0 -- no opinion [ ] -1 -- it's not ready yet (why?) For the records: me +1 I'll keep the vote open until 2011-01-14. Best regards, Johannes [1] http://sourceforge.net/mailarchive/message.php?msg_id=26836726 [2] http://sourceforge.net/mailarchive/message.php?msg_id=26865846 [3] http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/ |
|
From: Johannes S. <jsc...@t8...> - 2011-01-08 15:35:16
|
Hi all, there is another change I'd like to see in PHPTMAPI 2.0.1: 4) Constrain the parameter in Reifiable::setReifier() to Topic or null Reifiable::setReifier() [1] should be changed as follows: setReifier($reifier) -> setReifier(Topic $reifier=null) This is the standard declaration in PHPTMAPI 2.0 where a parameter can be Topic or NULL. I will start a vote on the proposed changes within the next days. Best regards, Johannes [1] http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/core/Reifiable.interface.php?revision=51&view=markup |
|
From: Johannes S. <jsc...@t8...> - 2011-01-02 21:44:56
|
Hi all,
I'd like to discuss a proposal for version 2.0.1 of PHPTMAPI which
includes the following changes:
1) Retrieval of TopicMapSystemFactory's implementation in
TopicMapSystemFactory::newInstance() [1] (thanks Alain):
In current version 2.0 the private static
TopicMapSystemFactory::getImplementationClass() returns an instance of
the implemented TopicMapSystemFactory by using the "new" operator -
however an instance should be created exclusively in
TopicMapSystemFactory::newInstance() by calling
TopicMapSystemFactoryImpl::newInstance().
Thus, the proposed change here is to rename getImplementationClass() as
getImplementationClassName() which only returns the implementation class
name - and not an instance. The class name is then used in newInstance()
to retrieve an instance of the concrete TopicMapSystemFactory.
I have attached a patch for better illustration.
2) Throw InvalidArgumentException in TypeInstanceIndex::getTopics() [2]
Throw an InvalidArgumentException in TypeInstanceIndex::getTopics() if
param. $types does not exclusively contain topics.
InvalidArgumentException is part of Standard PHP Library (SPL).
3) Force type "array" for parameter $themes in ScopedIndex methods and
extend PHP docs [3]:
The methods should be changed as follows:
a) getAssociations($themes, $matchAll) -> getAssociations(array $themes,
$matchAll)
b) getNames($themes, $matchAll) -> getNames(array $themes, $matchAll)
c) getOccurrences($themes, $matchAll) -> getOccurrences(array $themes,
$matchAll)
All these methods throw an InvalidArgumentException if $themes does not
exclusively contain topics. The docs should be further extended
regarding the unconstrained scope: "If themes' length = 0, themes is
interpreted as the unconstrained scope."
Here is an example for getAssociations():
/**
* Returns the {@link Association}s in the topic map whose scope
property
* equals one of those <var>themes</var> at least. If themes'
length = 1,
* <var>matchAll</var> is interpreted <var>true</var>. If themes'
length = 0,
* <var>themes</var> is interpreted as the unconstrained scope.
* The return value may be an empty array but must never be
<var>null</var>.
*
* @param array Scope of the {@link Association}s to be returned.
* If <var>themes</var> is an empty array all
{@link Association}s in the
* unconstrained scope are returned.
* @param boolean If true the scope property of an association must
match all themes,
* if false one theme must be matched at least. If themes'
length = 1, matchAll
* is interpreted true.
* @return array An array containing {@link Association}s.
* @throws InvalidArgumentException If <var>themes</var> does not
exclusively contain
* {@link Topic}s.
*/
d) getVariants($themes, $matchAll) -> getVariants(array $themes, $matchAll)
getVariants throws an InvalidArgumentException if $themes is an empty
array, or if $themes does not exclusively contain topics.
Thoughts?
Best regards,
Johannes
[1]
http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/core/TopicMapSystemFactory.class.php?revision=32&view=markup
[2]
http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/index/TypeInstanceIndex.interface.php?revision=27&view=markup
[3]
http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/index/ScopedIndex.interface.php?revision=9&view=markup
|
|
From: Johannes S. <jsc...@t8...> - 2011-01-02 21:44:34
|
Hi all,
I'd like to discuss a proposal for version 2.0.1 of PHPTMAPI which
includes the following changes:
1) Retrieval of TopicMapSystemFactory's implementation in
TopicMapSystemFactory::newInstance() [1] (thanks Alain):
In current version 2.0 the private static
TopicMapSystemFactory::getImplementationClass() returns an instance of
the implemented TopicMapSystemFactory by using the "new" operator -
however an instance should be created exclusively in
TopicMapSystemFactory::newInstance() by calling
TopicMapSystemFactoryImpl::newInstance().
Thus, the proposed change here is to rename getImplementationClass() as
getImplementationClassName() which only returns the implementation class
name - and not an instance. The class name is then used in newInstance()
to retrieve an instance of the concrete TopicMapSystemFactory.
I have attached a patch for better illustration.
2) Throw InvalidArgumentException in TypeInstanceIndex::getTopics() [2]
Throw an InvalidArgumentException in TypeInstanceIndex::getTopics() if
param. $types does not exclusively contain topics.
InvalidArgumentException is part of Standard PHP Library (SPL).
3) Force type "array" for parameter $themes in ScopedIndex methods and
extend PHP docs [3]:
The methods should be changed as follows:
a) getAssociations($themes, $matchAll) -> getAssociations(array $themes,
$matchAll)
b) getNames($themes, $matchAll) -> getNames(array $themes, $matchAll)
c) getOccurrences($themes, $matchAll) -> getOccurrences(array $themes,
$matchAll)
All these methods throw an InvalidArgumentException if $themes does not
exclusively contain topics. The docs should be further extended
regarding the unconstrained scope: "If themes' length = 0, themes is
interpreted as the unconstrained scope."
Here is an example for getAssociations():
/**
* Returns the {@link Association}s in the topic map whose scope
property
* equals one of those <var>themes</var> at least. If themes' length
= 1,
* <var>matchAll</var> is interpreted <var>true</var>. If themes'
length = 0,
* <var>themes</var> is interpreted as the unconstrained scope.
* The return value may be an empty array but must never be
<var>null</var>.
*
* @param array Scope of the {@link Association}s to be returned.
* If <var>themes</var> is an empty array all {@link
Association}s in the
* unconstrained scope are returned.
* @param boolean If true the scope property of an association must
match all themes,
* if false one theme must be matched at least. If themes'
length = 1, matchAll
* is interpreted true.
* @return array An array containing {@link Association}s.
* @throws InvalidArgumentException If <var>themes</var> does not
exclusively contain
* {@link Topic}s.
*/
d) getVariants($themes, $matchAll) -> getVariants(array $themes, $matchAll)
getVariants throws an InvalidArgumentException if $themes is an empty
array, or if $themes does not exclusively contain topics.
Thoughts?
Best regards,
Johannes
[1]
http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/core/TopicMapSystemFactory.class.php?revision=32&view=markup
[2]
http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/index/TypeInstanceIndex.interface.php?revision=27&view=markup
[3]
http://phptmapi.svn.sourceforge.net/viewvc/phptmapi/phptmapi2.0/trunk/index/ScopedIndex.interface.php?revision=9&view=markup
|
|
From: Johannes S. <top...@fr...> - 2010-02-14 21:55:51
|
Hi all, I'd like to release RC1 as version 2.0 on Monday. This is the last chance for serious objections :) Best regards, Johannes |
|
From: Johannes S. <top...@fr...> - 2010-02-07 14:26:58
|
Hi Lars, Lars Heuer schrieb: > > I still think that these methods are useless in the PHP world. I thought that they are useful for the TM world/scope. QTM uses equals() 27 times to check whether two TM constructs are equal ($this->getId() === $other->getId()). Yes, I could "introduce" them in QTM, however I guess that other implementors would also introduce a method like equals(). So why not providing it in PHPTMAPI? (Well, it's an assumption.) > If I'd > have more deep PHP OOP skills, I'd give a more precise advice, but I > am not familiar with PHP OOP (anymore). > > If you want to keep them, why don't you keep the names as well? > It was just an idea to avoid Java people expecting same behavior as Java equals() and hashCode() :) Well, finally, I'm fine preserving the status quo (semantics and naming). This would allow us to release RC1 as final version 2.0. Best regards, Johannes > Best regards, > Lars > |
|
From: Lars H. <he...@se...> - 2010-02-06 17:08:20
|
Hallo Johannes, [...] > I think that preserving the status quo is ok. Obviously, the method > names cause specific expectations for, at least, Java people as equals() > and hashCode() are Java natives. We could change > equals() to equalsConstruct() and > hashCode() to constructHashCode() I still think that these methods are useless in the PHP world. If I'd have more deep PHP OOP skills, I'd give a more precise advice, but I am not familiar with PHP OOP (anymore). If you want to keep them, why don't you keep the names as well? Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Johannes S. <top...@fr...> - 2010-02-06 16:57:46
|
Hi Lars, hi all, I think that preserving the status quo is ok. Obviously, the method names cause specific expectations for, at least, Java people as equals() and hashCode() are Java natives. We could change equals() to equalsConstruct() and hashCode() to constructHashCode() to be more precise/explicit. Best regards, Johannes Lars Heuer schrieb: > Forgot to include the list.... again... > > > This is a forwarded message > > Date: Friday, February 5, 2010 4:11:31 PM > Subject: [Phptmapi-discuss] Construct::equals() and Construct::hashCode() > > ===8<==============Original message text=============== > > Hi Johannes, > > [...] > >>> Well, my proposal was to remove hashCode() and equals() since they >>> wouldn't be used by PHP anyway (i.e. if something is added as key to >>> an array), but the behaviour of the implementations must be >>> predictable of course (c.f. unit tests). >>> > > >> not sure what you mean by "predictable". Do you have an example? >> > > predictable: All implementations must behave the same. You wrote in > another e-mail: > > """ > [...] comparison of objects is then delegated to implementors > """ > > I just wanted to ensure this does not open the door for > incompatibilities between implementations. > > Best regards, > Lars > |
|
From: Lars H. <he...@se...> - 2010-02-05 17:46:28
|
Forgot to include the list.... again...
This is a forwarded message
Date: Friday, February 5, 2010 4:11:31 PM
Subject: [Phptmapi-discuss] Construct::equals() and Construct::hashCode()
===8<==============Original message text===============
Hi Johannes,
[...]
>> Well, my proposal was to remove hashCode() and equals() since they
>> wouldn't be used by PHP anyway (i.e. if something is added as key to
>> an array), but the behaviour of the implementations must be
>> predictable of course (c.f. unit tests).
> not sure what you mean by "predictable". Do you have an example?
predictable: All implementations must behave the same. You wrote in
another e-mail:
"""
[...] comparison of objects is then delegated to implementors
"""
I just wanted to ensure this does not open the door for
incompatibilities between implementations.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
===8<===========End of original message text===========
|
|
From: Johannes S. <top...@fr...> - 2010-02-05 14:41:54
|
Hi Lars,
Lars Heuer schrieb:
> Well, my proposal was to remove hashCode() and equals() since they
> wouldn't be used by PHP anyway (i.e. if something is added as key to
> an array), but the behaviour of the implementations must be
> predictable of course (c.f. unit tests).
>
not sure what you mean by "predictable". Do you have an example?
Using objects as keys like
$topics[$topic1] = 'foo';
$topics[$topic2] = 'bar';
and then doing
count($topics);// 1 or 2
is in the scope of PHP (comparison of objects). In contrast, in a TM
scope there should be answered the question if $topic1 represents the
same TM construct (Topic) as $topic2. (Or: represent the same subject on
Topic level which then may trigger merging.) Answer could be TRUE
although spl_object_hash($topic1) != spl_object_hash($topic2) holds.
Implementors could introduce equalsConstruct(Construct $construct):
if (!$topic1->equalsConstruct($topic2) {
$topics[$topic2] = 'bar';
}
Best regards,
Johannes
> Best regards,
> Lars
>
|
|
From: Lars H. <he...@se...> - 2010-02-04 15:03:52
|
Hi Johannes, > there is also the idea of Lars Heuer to just abolish equals() and > hashCode(). Comparison of TM constructs as well as comparison of objects > is then delegated to implementors. Well, my proposal was to remove hashCode() and equals() since they wouldn't be used by PHP anyway (i.e. if something is added as key to an array), but the behaviour of the implementations must be predictable of course (c.f. unit tests). Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Johannes S. <top...@fr...> - 2010-02-03 20:37:39
|
Hi there, there is also the idea of Lars Heuer to just abolish equals() and hashCode(). Comparison of TM constructs as well as comparison of objects is then delegated to implementors. Johannes Johannes Schmidt schrieb: > Hi all, > as PHPTMAPI is aligned to TMAPI I now wanted to update > Construct::equals() and Construct::hashCode() according to updated > semantics of equals() and hashCode() in final RC of TMAPI 2.0 [1]. Well, > I am not really satisfied with this changing but missed the discussion > on TMAPI mailing list. In final RC the semantics of equals() has changed > from comparing the identity of TM CONSTRUCTS towards comparing the > identity of (Java) OBJECTS. This is significantly different. Identity of > TM constructs is "materialized" by TM system specific arbitrary > identifiers [2]. IMO in federation of different topic maps from > different TM systems processing of such construct identifiers must be > omitted; focus is on processing the identity of subjects. > To be honest: I'd like to preserve current semantics of PHPTMAPI > equals(). Implementors will know how to identify PHP objects [3]. Thoughts? > > Best regards, > Johannes > > > [1] > http://sourceforge.net/mailarchive/forum.php?thread_name=1521353800.20100113175400%40semagia.com&forum_name=tmapi-discuss > [2] http://phptmapi.sourceforge.net/2.0/docs/core/Construct.html#getId > [3] http://www.php.net/manual/en/language.oop5.object-comparison.php > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Phptmapi-discuss mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phptmapi-discuss > > > |
|
From: Johannes S. <top...@fr...> - 2010-02-02 22:33:57
|
Hi all, as PHPTMAPI is aligned to TMAPI I now wanted to update Construct::equals() and Construct::hashCode() according to updated semantics of equals() and hashCode() in final RC of TMAPI 2.0 [1]. Well, I am not really satisfied with this changing but missed the discussion on TMAPI mailing list. In final RC the semantics of equals() has changed from comparing the identity of TM CONSTRUCTS towards comparing the identity of (Java) OBJECTS. This is significantly different. Identity of TM constructs is "materialized" by TM system specific arbitrary identifiers [2]. IMO in federation of different topic maps from different TM systems processing of such construct identifiers must be omitted; focus is on processing the identity of subjects. To be honest: I'd like to preserve current semantics of PHPTMAPI equals(). Implementors will know how to identify PHP objects [3]. Thoughts? Best regards, Johannes [1] http://sourceforge.net/mailarchive/forum.php?thread_name=1521353800.20100113175400%40semagia.com&forum_name=tmapi-discuss [2] http://phptmapi.sourceforge.net/2.0/docs/core/Construct.html#getId [3] http://www.php.net/manual/en/language.oop5.object-comparison.php |
|
From: Lars H. <he...@se...> - 2010-01-03 17:12:15
|
Hi all, > P.S. Didn't have the time yet to check Lars' topic map to PHP conversion. Today, I installed QuaaxTM and checked the script. I found a few bugs like missing semicolons etc. If you use rev. 335, everything should work. I added an example topic map. The import is very expensive and may exceed the execution time limit for PHP scripts. A more advanced script may bypass PHPTMAPI and use QuaaxTM directly (i.e. controlling the transactions etc.) or create a bunch of SQL statements and bypass PHP at all. Anyway, the script seems to be useful for small topic maps, i.e. to initialize a system topic map. Best regards, Lars -- Semagia <http://www.semagia.com/> |
|
From: Johannes S. <top...@fr...> - 2009-12-30 11:26:52
|
Hi Andrius,
you DON'T have to run the tests - I thought running the tests is a
comfortable way to check if QTM is ready. Anyway, as mentioned in README
looking at AllCoreTests.php (contains the test suite) shows you how QTM
is used/included in existing projects ("you just have to include
TopicMapSystemFactory.class.php from PHPTMAPI") once you have edited
lib/phptmapi2.0/config.php correctly.
Best regards,
Johannes
P.S. Didn't have the time yet to check Lars' topic map to PHP conversion.
Lars Heuer wrote:
> Again, on behalf of Andrius
>
> Johannes: Any idea?
>
>
>
> This is a forwarded message
>
> From: Andrius Lauraitis
> To: Lars Heuer
> Date: Tuesday, December 29, 2009 8:56:16 PM
> Subject: [Phptmapi-discuss] Fwd: Re: Fwd: Re: About simple example
>
> ===8<==============Original message text===============
>
> Thanks for the converted file :) I'm getting interested. Now i need somehow
> to install properly QuaaxTM in order to use those libraries... I'm wondering
> if i haven't tried phpunit tests will QuaaxTM still work?... I've tried to
> install phpunit via pear but got an error with memory...
>
> 2009/12/29 Lars Heuer
>
>
>> Hi Andrius,
>>
>>
>>> Ok, so i send a simple xtm file. Maybe you could translate ir to php and
>>> explain a bit how to run the generated code on my wamp server :) Thanks
>>>
>> I attached the generated file.
>>
>> You have to invoke the populate_map function with an instance of
>> TopicMap.
>>
>> I.e.: (caution my PHP skills are rusty):
>>
>> <?php
>> require_once('example_jill.xtm.php');
>>
>> // Init the TopicMapSystemFactory etc here.
>> // [...]
>>
>> $tm =
>> $topicMapSystem->createTopicMap('http://www.example.org/example_jill.xtm'
>> );
>>
>> populate_map($tm);
>>
>> ?>
>>
>> Best regards,
>> Lars
>> --
>> Semagia
>> <http://www.semagia.com>
>>
>>
>
>
> ===8<===========End of original message text===========
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Phptmapi-discuss mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phptmapi-discuss
>
>
>
|
|
From: Lars H. <he...@se...> - 2009-12-29 19:59:49
|
Again, on behalf of Andrius
Johannes: Any idea?
This is a forwarded message
From: Andrius Lauraitis
To: Lars Heuer
Date: Tuesday, December 29, 2009 8:56:16 PM
Subject: [Phptmapi-discuss] Fwd: Re: Fwd: Re: About simple example
===8<==============Original message text===============
Thanks for the converted file :) I'm getting interested. Now i need somehow
to install properly QuaaxTM in order to use those libraries... I'm wondering
if i haven't tried phpunit tests will QuaaxTM still work?... I've tried to
install phpunit via pear but got an error with memory...
2009/12/29 Lars Heuer
> Hi Andrius,
>
> > Ok, so i send a simple xtm file. Maybe you could translate ir to php and
> > explain a bit how to run the generated code on my wamp server :) Thanks
>
> I attached the generated file.
>
> You have to invoke the populate_map function with an instance of
> TopicMap.
>
> I.e.: (caution my PHP skills are rusty):
>
> <?php
> require_once('example_jill.xtm.php');
>
> // Init the TopicMapSystemFactory etc here.
> // [...]
>
> $tm =
> $topicMapSystem->createTopicMap('http://www.example.org/example_jill.xtm'
> );
>
> populate_map($tm);
>
> ?>
>
> Best regards,
> Lars
> --
> Semagia
> <http://www.semagia.com>
>
===8<===========End of original message text===========
|
|
From: Lars H. <he...@se...> - 2009-12-29 19:30:07
|
Hi Andrius, [...] > Hmm, seems complicated :) :) Yeah, maybe. As said, QuaaxTM provides no topic map importers yet, so you cannot import topic maps from XTM sources. That scripts gives you the possibility to convert any topic map into a PHP-Script. The generated PHP script can be used to populate your topic map with content. [...] > How do you deal with topic maps yourself? I use Python (Mappa [1]) or Java (Ontopia [2], tinyTiM [3]). I am just a lurker at this mailing list. The converter was just an experiment. > I was wondering if XTM file could be parsed into XML file... An XTM file is an XML file. XTM is the abbreviation of "XML Topic Maps". > Besides, i'm not sure if i've successfully installed QuaaxTM, > because my phpunit tests does not run...Maybe there is a way to see > in my wamp server, if QuaaxTM is installed. Thank you :) Sorry, I cannot help here. As said, I do not use PHPTMAPI. But I think Johannes can tell you how to install QuaaxTM. [1] <http://mappa.googlecode.com/> [2] <http://ontopia.googlecode.com/> [3] <http://tinytim.sourceforge.net/> Best regards, Lars -- Semagia <http://www.semagia.com> |
2 messages has been excluded from this view by a project administrator.
