Hi, does anybody have a ML xml.gz von spider-admin available? I cannot use DG and the convert_to_mu7ltilang script fails. Live long and prosper! Torben Nehmer -- -- Torben Nehmer, Guenzburg, Bavaria, Germany http://www.nathan-syntronics.de, mailto:torben@... PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
torben@... wrote: > does anybody have a ML xml.gz von spider-admin available? I cannot use DG 1. create database 2. import empty sql 3. import spider with repligard ( using non ml repligard schema file ) 4. run dg and select database update > and the convert_to_mu7ltilang script fails. We have never used it. If everything fails: http://infoglob.pl/~pp/spider-admin_multilang.xml.gz Piotras
Hi, --rambo@... wrote on 2006-02-06 13:18: > Log: initial working version of an "AT" service TODO (if you want to stay in core code): Adhere to coding styleguide Complete documentation for all non-derived members and for derived members with significant functionality Recommend changes for readability / stability for maximum core "code compatibility": no while (list = each), use foreach. if unserialization for entries fail, check for it (if (! $unserialized)), this should always be done if you @ silence the unserialize call. replace $_MIDCOM->dbfactory->new_query_builder($class) with $class::new_query_builder() <-- official OO DBA API MidCOM QBs need (as in should never) be @ silenced. Report errors to the user when you fail. (There is a print_error in midcom_baseclasses_components_cron_handler, RTFM!) The called jobs should always get a reference to the cron handler so that they too can print error messages where required. Live long and Prosper! Torben Nehmer -- Torben Nehmer, Guenzburg, Bavaria, Germany(Continue reading)
Hi,
--Torben Nehmer wrote on 2006-02-06 13:30:
> TODO (if you want to stay in core code):
> [...]
Two more things:
> CREATE TABLE midcom_services_at_entry_db (
> [...]
> PRIMARY KEY (id),
> KEY oocmsgreceipt_sitegroup_idx(sitegroup)
>);
a) The key naming is broken. All components in the main midcom CVS use the
semantics {$table_name}_{$index_name} for naming indexes to avoid namespace clashes.
b) Consider adding a furthe index over the start column to speed up queries.
Live long and Prosper!
Torben Nehmer
--
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:torben@...
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
Hi, out of frustration with the current M-T I have written a draft mRFC for how Midcom Templates should be handled in the future. Please read through it and comment it. I haven't added it to the mRFC's list yet as I want to see if the ideas presented are usefull in this form. MRFC: Midgard site startup and configuration. This is an outline for how future MidCOM Sites should be created and configured. Background: The current solution to set up MidCOM sites uses the Midgard Template to create sites. The current template is slow and is hard to modify and work with. For those who do not know, the following is an example of the setup of a very basic MidCOM site. Midcom goes through three stages: 1. initialization and startup 2. Content output 3. Ending. The most basic site template for use in MidCOM is this: <?php $GLOBALS['midcom_config_local']['midcom_root_topic_guid'] = "860f1b5af98b409abd916a80cdb0d68e"; require 'midcom.php'; $_MIDCOM->codeinit(); ?>(Continue reading)
Tarjei Huse <tarjei@...> wrote: Hi, ( do not kill me ;) > MRFC: Midgard site startup and configuration. > > This is an outline for how future MidCOM Sites should be created and > configured. > > Background: > The current solution to set up MidCOM sites uses the Midgard Template to > create sites. The current template is slow and is hard to modify and > work with. I am not any component developer but: Two sites I initilized without M-T are not working anymore and frankly speaking I have no time or will to debug what happened. However M-T is slow I vote for M-T. Reason is very simple. I know that M-T based sites are going to work as expected. > Site configuration > Today site configuration is contained in parameters to the host. This is > fairly inefficient as this generates a large set of queries to the > database on every request. > > Instead of keeping the configuration in parameters it should be kept in > a simple snippet that may be included into the request. > > This snippet should be named:(Continue reading)
Correct me if im wrong .. but i think that torben and bergie has talked about moving the majority of m-t into midcom .. and make a minimal version of m-t that only initialises the site .. /Johan "SmallOne" Bernhardsson On Tue, 2006-02-07 at 10:20 +0100, Piotras wrote: > Tarjei Huse <tarjei@...> wrote: > > Hi, > ( do not kill me ;) > > > MRFC: Midgard site startup and configuration. > > > > This is an outline for how future MidCOM Sites should be created and > > configured. > > > > Background: > > The current solution to set up MidCOM sites uses the Midgard Template to > > create sites. The current template is slow and is hard to modify and > > work with. > > I am not any component developer but: > Two sites I initilized without M-T are not working anymore and frankly speaking > I have no time or will to debug what happened. > However M-T is slow I vote for M-T. Reason is very simple. I know that M-T based > sites are going to work as expected. > > > Site configuration > > Today site configuration is contained in parameters to the host. This is(Continue reading)
Hi all, --Tarjei Huse wrote on 2006-02-06 17:57: > Hi, out of frustration with the current M-T I have written a draft mRFC > for how Midcom Templates should be handled in the future. Please read > through it and comment it. I haven't added it to the mRFC's list yet as > I want to see if the ideas presented are usefull in this form. First of all good work(Continue reading)A few remarks: > The most basic site template for use in MidCOM is this: > <?php > $GLOBALS['midcom_config_local']['midcom_root_topic_guid'] = > "860f1b5af98b409abd916a80cdb0d68e"; > require 'midcom.php'; > $_MIDCOM->codeinit(); > ?> > [...] Fully correct. On a personal note, I usually use startup code like this one, for better readability (see below for notes): // ============ CONFIG START $config = Array(); $config['midcom_ais_url'] = '/admin/';
Hi again. --Piotras wrote on 2006-02-07 10:20: > I am not any component developer but: Two sites I initilized without M-T are > not working anymore and frankly speaking I have no time or will to debug what > happened. However M-T is slow I vote for M-T. Reason is very simple. I know > that M-T based sites are going to work as expected. You think so, ok. I have nearly a dozen of examples where current M-T broke more things, than it fixed. It is purely a matter of perspective. We need a site management system, but not something like current M-T. > $some_midcom_object->root is much more readable than arrays' hell. > > [...] > > $some_midcom_site->port > $some_midcom_site->prefix > $some_midcom_site->whatever > > Is *much* more readable than another set of huge set of arrays. Leading to a table which needs to be extended with each and every configuration option I add to MidCOM. Right now, we already have literally dozens of such options (around 50 I guess) part of which are system-wide, part of it site-specific. Some options are even complex types, not simple ports or prefixes. Using a DB table is no real option here as it lacks flexibility. See my other(Continue reading)
RSS Feed131 | |
|---|---|
269 | |
108 | |
240 | |
116 | |
103 | |
93 | |
179 | |
126 | |
34 | |
123 | |
77 | |
96 | |
42 | |
73 | |
72 | |
71 | |
64 | |
80 | |
38 | |
84 | |
24 | |
118 | |
158 | |
306 | |
96 | |
94 | |
152 | |
301 | |
115 | |
227 | |
126 | |
188 | |
258 | |
216 | |
369 | |
193 | |
140 | |
219 | |
232 | |
228 | |
202 | |
343 | |
288 | |
36 | |
1 |
