Menu
▾
▴
aplaws-devel — Developer Mailing List. Forum postings are forwarded to this list.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(13) |
Mar
(15) |
Apr
(29) |
May
(28) |
Jun
(111) |
Jul
(185) |
Aug
(366) |
Sep
(121) |
Oct
(73) |
Nov
(57) |
Dec
(23) |
| 2005 |
Jan
(30) |
Feb
(49) |
Mar
(51) |
Apr
(47) |
May
(95) |
Jun
(74) |
Jul
(62) |
Aug
(61) |
Sep
(46) |
Oct
(73) |
Nov
(111) |
Dec
(59) |
| 2006 |
Jan
(114) |
Feb
(34) |
Mar
(47) |
Apr
(49) |
May
(106) |
Jun
(47) |
Jul
(78) |
Aug
(31) |
Sep
(35) |
Oct
(39) |
Nov
(63) |
Dec
(17) |
| 2007 |
Jan
(40) |
Feb
(32) |
Mar
(17) |
Apr
(15) |
May
(28) |
Jun
(20) |
Jul
(80) |
Aug
(83) |
Sep
(52) |
Oct
(26) |
Nov
(6) |
Dec
(9) |
| 2008 |
Jan
(22) |
Feb
(11) |
Mar
(45) |
Apr
(5) |
May
(8) |
Jun
|
Jul
(16) |
Aug
(5) |
Sep
(3) |
Oct
(4) |
Nov
(14) |
Dec
(3) |
| 2009 |
Jan
(25) |
Feb
(46) |
Mar
(17) |
Apr
(8) |
May
(74) |
Jun
(48) |
Jul
(11) |
Aug
(9) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 03:42:41
|
Hi, Just a quick hello to everyone out there, I have recently started working with Permeance in Western Australia and hope to be contributing to APLAWS as part of the work for some of the government agencies here in WA. Cheers, Tim |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 03:00:37
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470834 By: terry_permeance Okay. I think we should use a term/acronym that anybody would know without doing a search. It's a usability issue I guess. It still prefer: c.adcms.ct.<content-type>.<field-name>.editor=(wysiwyg|text) where "text" is the default but I'll go with whatever the community thinks is best :-) Thanks, Terry ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 01:52:25
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470745 By: pboy Terry, > I'm not sure what "rft" rtf = richt text field, that is the term the dhtml editor people are naming the text area were a WYSIWYG editor is used instead of the plain text. > I can't claim credit for the coding. I'm committing code from our new developer Tim Carpenter > who is being inducted into APLAWS as we speak. Yes, I got his application for write access and will grant it to him asap. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 01:48:15
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470743 By: pboy Terry, OK, obviously I perfectly missunderstood it (it is very late here in Germany :-) ) I thought you were referring to authoring steps. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 01:40:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470736 By: terry_permeance I wish we could attach screendumps to these emails :-( This change simply makes it possible to hide the [Upload a file] link when editing a Body Text after which the only option seen is the [Edit as text] link. Apparently some of our users are have been trying to import M$ Word documents into the Body Text hoping it will convert it! Regards, Terry ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 01:33:25
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470731 By: terry_permeance I'm not sure what "rft" is so I would propose the following convention: c.ad.ct.cms.<content-type>.<field-name>.editor=(wysiwyg|text) Regards, Terry P.S. I can't claim credit for the coding. I'm committing code from our new developer Tim Carpenter who is being inducted into APLAWS as we speak. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 01:22:36
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470713 By: pboy Terry, if I understand it right we have already a similiar feature, contributed by ChrisGilbert23 (see r1434). Did you study his patch? Or did I missunderstand the purpose? Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 01:03:10
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470687 By: pboy Terry, just have seen that you already have committed the patch. Nevertheless, we should introduce a nameing pattern, eg. c.ad.cms.<content-type>.<field-name>-as-rft or something like that. > ccm set com.arsdigita.cms.contenttypes.glossaryitem.fck_editor_config=<path> > (uses fckconfig_forum.js by default) I think fckconfig_forum as default is a bad idea because it introduces a horizontal dependency between modules (which is generally a bad design, especially in this case because they are independet by its purpose and usage). So it should either use a default configuration as specified in cms (because glossary is a ccm-cms-types-<module> so it generates no additional module dependency). Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 00:46:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470666 By: pboy Terry, I think that is a good idea and should be implemented. I did something similiar with a field of the event contenttyp and introduced > com.arsdigita.cms.contenttypes.event.use_html_date_description=false|true So may be should enable/disable dhtml on a per field base (as a systematic structure for any content type we may modify this way)? Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 00:37:36
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470657 By: pboy Brett, > > It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource > > can be lookup up in multiple contexts > That works very well for the core dispatcher, but does not work inside of xml files (include directive, a mechansim > which is widely used in APLAWS). Therefore, if we decide that every module must be able to run in its own context, > we have to find a solution. Sorry, I forgot that you already developed a solution for this part. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-30 00:32:08
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470649 By: pboy Hi Brett, > The problem is that the presentation layer depends upon Bebop XSLT in ccm-core. > Each module should be able to run in its own context but it also needs to access the core XSLT > components of Bebop. I don't think each individual module should have it's own copy of the core resources. Is it really true, that each module should be able to run in its own context? I asked on the forum and tried hard to find a reason for it. E.g. why should ccm-ldn-theme run in its own context? By design (i.e. the xml include mechanism) it provides services for just one web application, that one that is running in ROOT. Nothing else. It used to store all the themes in its own context, but a theme is very specific to a web application, no one wants to mix themes between several web applications. Of course, several web applications might use the services, the module ccm-ldn-themes provides. Therefore, the jar files might be / should be stored in the containers shared lib directory so it can be used by any web application. But each web application will store the themes in its ówn context (xsl but also logo, images and other private or specific things the webapp might not be willing to share). And it will store the theme of the admin interface in its own context and might whish to modify or redesign it. As to my knowledge version 5 of APLAWS was a JEE application, were all modules were installed into one context (ccm). Do you know, WHY that had been changed? I suppose I never understood this design decision. Currently, the development system had been changed so that all modules are installed into one context which is specified in project.xml. If there is a requirement, that a module should run in its own context, I have to adjust the build-template.xsl. Just another topic: If each module is dependent from resources in core, I suppose it is an example of (very) strong coupling. So it should not divided into different modules (at least according to theory :-) ) > It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource > can be lookup up in multiple contexts That works very well for the core dispatcher, but does not work inside of xml files (include directive, a mechansim which is widely used in APLAWS). Therefore, if we decide that every module must be able to run in its own context, we have to find a solution. Therefore the question is: Is it essential for your usage of APLAWS / CCM that each module is able to run in its own context, or is it sufficient that jar files are stored in a shared directory or can we determine specific circumstances for the requirement to run in ist own context (some sort of special kind or types of modules) for which we can develope a solution for the include directive in xsl files (of make them unneccessary). Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-29 18:50:10
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7470171 By: bprucha > I think XML templates, which render a xml information to html, are very private > to the module which maintains that information. It should never be used by any > other module directly, and even more so by another web application The problem is that the presentation layer depends upon Bebop XSLT in ccm-core. Each module should be able to run in its own context but it also needs to access the core XSLT components of Bebop. I don't think each individual module should have it's own copy of the core resources. > if there is a need to access that information, an jee service or a content type > as proxy site or xmlfeed should be used The stylesheet-paths.txt file describes where to look for these resources and by default points to the resource-resolver servlet through an absolute URL. The templating system translates this into a call to resolve the resource from the local context to optimize resource lookup. > Why not fetch it from the we applications context? It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource can be lookup up in multiple contexts. > Even more worse with c.ad.caching.CacheServlet. It reads the host's name and > port from a persistent database table I've never had to change these values so haven't run into this problem. It's used to support clustering I suppose. I haven't ever looking into it since I've never changed the host name or used clustering. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-29 03:28:25
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7468967 By: terry_permeance PURPOSE Glossary item should use a WYSIWYG editor CONFIGURATION ccm set com.arsdigita.cms.contenttypes.glossaryitem.use_dhtml_editor=true (to enable, false by default) ccm set com.arsdigita.cms.contenttypes.glossaryitem.fck_editor_config=<path> (uses fckconfig_forum.js by default) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-29 03:26:40
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7468965 By: terry_permeance Purpose The [Upload a file] option is not required for some clients. Changes Use com.arsdigita.cms.hide_text_asset_upload_file configuration to turn this off. (default is enabled for backwards compatibility) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-27 19:31:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7467376 By: pboy Hi Brett, thank you very much for the work to inspect the Alfresco code. I think, a dependency from lucene indexes for efficient data lookups is an obsolute "KO criterion". We are all glad that the performance problems of the early APLAWS / CCM version could be resolved by extensive caching and tuning persistence. So, we should take the hibernate route. According to Jens' proposal we may construct an interface which allows to connect to hibernate or to JCR,when JCR becomes mature. CCM follows an highly sophisticated object oriented design which we should not dispense. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-24 15:26:17
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7461752 By: bprucha Just to throw my $.02 in, I agree with others about adopting Hibernate or another implementation of Java Persistence API. It is a standard just like JCR so I don't get the argument that companies will want JCR over it. It fits in well with the exising architecture. I have looked into the Alfresco code and it's use of JCR and I considered the design very messy and not scalable. The developers of Alfresco had to rely on Lucene indexs to provide efficient data lookup. Having to sync the Lucene index with the JCR data was a real burden and caused unexpected results when they weren't synced properly. Relational databases still rule and JCR has not proven itself IMHO. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-24 06:26:25
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7460837 By: jensp1108 Maybe there is an option which allows us to support the JPA and JCR. The JPA is designed for persisting Java Beans is an relational database. This task is called Object Relational Mapping (ORM). The JPA uses annotations or XML files to mark the properties which should be stored into the database. The Apache Jackrabbit provides something very similar for the JCR. They call it Object Content Mapping (OCM): http://jackrabbit.apache.org/object-content-mapping.html. OCM works very similar to the JPA. The objects to store must be Java Beans, and you mark the properties to store with annotations or in a XML file. So if we use XML files for the JPA instead of annotations we can switch very easily to JCR. The methods needed for reading and writing are very similar, so that it should be easy to design an interface containing these methods. This interface would be implemented by a class which maps the methods from the interface to the concrete methods of the JPA or the Jackrabbit OCM implementation. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-23 19:27:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7460154 By: bprucha Just to throw my $.02 in, I agree with others about adopting Hibernate or another implementation of Java Persistence API. It is a standard just like JCR so I don't get the argument that companies will want JCR over it. It fits in well with the exising architecture. I have looked into the Alfresco code and it's use of JCR and I considered the design very messy and not scalable. The developers of Alfresco had to rely on Lucene indexs to provide efficient data lookup. Having to sync the Lucene index with the JCR data was a real burden and caused unexpected results when they weren't synced properly. Relational databases still rule and JCR has not proven itself IMHO. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-20 09:34:07
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7454926 By: csgupta Thanks Peter, When i start tomcat there is no default lucene directory created under work. as it used to be with previous Aplaws version.. Since my trunk build is working fine for me now i am preparing the code patch for Nutch integration. I have created couple of java file in com.arsdigita.search and also i have introduced one field in Queryspecification.java to differentiate whether it is content search or external search(Nutch Lucene binary). Also some config file i have placed in ccm-core src and nutch related jar files like hadoop and nutch jar in ccm-core lib directory. As i discussed with you before you suggested to keep ccm-core as much as possible as core ... Shall i create a separate package or is that ok? I think If somebody would not be interested in nutch package although they will have the nutch code in ccm-core..if we see on that point of view i must keep nutch integration code in separate package. /Chandra ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-20 08:42:37
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7454896 By: pboy Hi Chandra, lucene data directory has been moved to ~/WEB-INF/work or ~/WEB-INF/work/lucene. Good luck Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-20 08:26:47
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7454866 By: csgupta any idea where is lucene data directory using ECDC build on latest trunk? Chandra ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-18 08:07:53
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7451077 By: pboy | organisations are more likely to be diven by standards and will therefore be | looking for a product that supports the JCR standard and the upcoming | CMIS (Content Management Interoperability Services). Given the current market situation I'm not shure about that. :-) Nevertheless, Hibernate is one implementation of a standard (Java Persistence API). Organisations and users might look for features (e.g. support for different databases), usability, performance, etc. Hibernate (probably as an intermediate step) will open a chance for improvements in a foreseeable time frame. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-18 08:00:19
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7451067 By: pboy Francois, | would it mkae the roadmap easier to move from RedHat persistence to Hibernate | and then from Hibernate to JCR personally I have a slight preference to that route. If we move directly to JCR we have not only to rework and clean up the class hierarchy, the deprecated parts of the code, and all the unfinished work spreaded over several packages, but also to *redesign* large parts of the code as we move from an object relational persistence to a sort of hierarchical persistence. To perform all of that work in one step has - mathematically spoken - a lot of "degrees of freedom", may be to much, and carries the risk to evolve into an unmanageable, insolvable, never ending process. Hibernate is an implementation of the Java Persistence API, which inherited the basic design from the JDO framework which in turn has very similiar design principles as CCM persistence (which may be seen as a first draft of JDO). The migration process is better foreseeable and will result rather soon in a working, improved, and easier maintainable code base. A large part of the work is a quite mechanically refactoring, some sort of boring but very likely to be performed in a short time frame. From that level it is easier and better managable to migrate to JCR if we decide to do so. And: Currently nobody made a detailed analysis, whether JCR meets all the requirements of APLAWS's feature set or what changes are necessary. Given the current code state it is very difficult, perhaps impossible, to make such an analysis. Just my thoughts. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-18 01:04:02
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7450590 By: terry_permeance Yes, can you please commit the sql to your contrib folder? Regards, Terry ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-18 00:32:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7450550 By: terry_permeance If someone has a passion for converting aplaws to use Hibernate then by all means go for it. Personally, I think PDL does the job quite well. I think implementing standards such as JSR170 and JSR286 and so on are more important. Also, have a look at Mirage (https://mirage.dev.java.net/). It's kind of like the "apache commons" for CMS. Regards, Terry ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
7 messages has been excluded from this view by a project administrator.
