Messages

[log4j.logger.org.apache.torque.util.BasePeer = DEBUGlog4j.logger.com.konakart = DEBUGlog4j.logger.com.konakartadmin = DEBUG]

Hi Sphericus,

The answer is not obvious to me at this point, but you can help to diagnose the problem by turning on some of the log flags so that you can see what's happening.

Try settiing these and restarting tomcat:

log4j.logger.org.apache.torque.util.BasePeer  = DEBUG
log4j.logger.com.konakart                           = DEBUG
log4j.logger.com.konakartadmin                    = DEBUG

(Set these in webapps/konakartadmin/WEB-INF/classes/konakart-logging.properties)

(The first one will tell us more about the queries being executed which is probably what we need to see).

Hopefully this will give you some clues as to where the problem lies..  The obvious guess is that the data-loading has caused the problem...

Regards,
John

Hi Sphericus,

First of all I should tell you that we have introduced a specific SKU field for the next release.   It will appear in the products_quantity table as follows:

CREATE TABLE products_quantity(
   products_id int NOT NULL,
   products_options varchar(128) NOT NULL,
   products_quantity int NOT NULL,
   products_sku varchar(255),
   PRIMARY KEY (products_id, products_options)
);

You'll note that it's a varchar(255).
It will be accessible from the Admin App for modification and searching.

It might be best if you could map your existing product's SKU to this field if you can wait for the next release (it should be out in about 2 or 3 weeks).


But back to your question.   With the exception of some validation failing in some places (I'm thinking of the Admin App) I do not know of any problems that you would encounter if you simply extended database field lengths.   Changing types is more likely to cause problems.

Which field(s) are you thinking of extending?   Perhaps it is a column we might want to extend as a default for KonaKart in future?  It depends which column and whether it's still required given that we are introducing a specific products_sku column in the next release.    Another potential problem is that we do try to remain compatible at the database level with osCommerce; so we would have to take that into account as well.

Regards,
John

Hi Kastor,

Whilst it's quite horrible to do you can actually edit the huge javascript files of the Admin App.

You'll find them under /webapps/konakartadmin.    There are about 5 large html files wih generated names - they're easy to spot because they're the largest files in that directory.

Inside these you will find 'strings' that you can change... but do so with care not to change the wrong things, of course!!   I'd advise you to tread carefully and do a little bit at a time and keep checking that it's all still working.

A Chinese guy used this technique to create a Chinese version of the Admin App.

Not exactly easy to do and could be something that you might throw away when the next release comes out....  but there is a way to do it if you really need it now!!!

We'll be interested if you manage to do this and get a Spanish version of the Admin App.


Oh yes, thanks for contributing your spanish translation of the KonaKart message catalog.  I'm sure that will save a lot of people a great deal of time.

Regards,
John   

Hi Rambo 

Very good timing on this...   Development is already underway to provide a friendly way to internationalise the Admin App.  (Currently, in version 2.2.0.4, there is no easy way to do this).

This will be available in the next release (about 2 or 3 weeks off I expect).

It'll be a case of translating a message catalog in a properties file - just like you've seen for the main application.

Indeed, when you have translated the message catalog we would be grateful if you could share it as a contribution for others to use.   You can add such things to the Contributions section on this forum.

Regards,
John

Hi Kastor,

Thanks for reporting the problem on tomcat 5.5.23 and for your comment on the listing parameter.

Please see this post http://www.konakart.com/forum/index.php/topic,50.msg224.html#msg224 for a solution to the tomcat 5.5.23 problem.

Regards,
John

[/webapps/konakart/WEB-INF/web.xml]

Hi,

We just tried KonaKart on 5.5.23 and were able to reproduce the problem.

There would appear to be differences in the order that servlets are brought up in tomcat 5.5.23 over the tomcat 5.5.17.

This is easily solved by changing the konakart web.xml to set the order of the start-up of the KonakartGWTServlet servlet.

So, in ${konakart-home}/webapps/konakart/WEB-INF/web.xml modify this:

<!-- Servlet for GWT code -->
<servlet>
           <servlet-name>KonakartGWTServlet</servlet-name>
           <display-name>KonaKart GWT App</display-name>
           <description>KonaKart GWT App</description>
           <servlet-class>com.konakart.server.KKGWTServiceImpl</servlet-class>
           <load-on-startup/>
</servlet>

to this:

<!-- Servlet for GWT code -->
<servlet>
           <servlet-name>KonakartGWTServlet</servlet-name>
           <display-name>KonaKart GWT App</display-name>
           <description>KonaKart GWT App</description>
           <servlet-class>com.konakart.server.KKGWTServiceImpl</servlet-class>
           <load-on-startup>10</load-on-startup>
</servlet>


We'll modify the code so that it's not sensitive to the start-up order in the next release... but this should get you going for now.

Thanks for reporting the problem.

John

Perhaps the easiest way to do this is to run the wizard-based installation, setting the various configuration parameters as you like, then copying the following webapps that are produced to your existing tomcat webapps directory:

• birt_viewer


• konakart


• konakartadmin

The advantage of running the wizard installation is that it will populate the webapps with all the configuration values that you specify in all the right places without you having to do this manually.   Another advantage of the wizard installation is that it will check your database connection parameters and, optionally, populate your database with the tables and demonstration data ready to use KonaKart.

If, however, you prefer, you can just extract the above webapps from the zip version of the installation and configure KonaKart and load your database yourself...   there are FAQs available to help you with this. eg. http://www.konakart.com/installationfaq.php and http://www.konakart.com/configurationfaq.php

Good luck, and pease let us know how you get on.

John

Hi Sphericus,

"login" is part of the API so you can call it directly using plain java objects or over SOAP.   Everything in the interface is available either via java or SOAP.   Therefore, if I understand your question correctly, the answer is yes, you can call it remotely.

John

Hi Sphericus,

You have to use the "login" call of the admin engine interface, which returns a session Id which you use on subsequent calls.

eg:        wsSessionId = engWS.login(USERNAME, PASSWORD);

This is the username and password of the admin user.

Hope that helps,
John

Hello Dean,

1) The customizable parts of KonaKart are open source. These include the Struts action classes and forms, the JSPs, the payment modules, order total modules, shipping modules, discount modules and the one page checkout Google GWT code. This code is shipped under the GNU Lesser General Public License. The remaining components of KonaKart are free, but not open source.

2) "Is anything we might conceivably need to already open source?"    Sorry, I don't understand your question here.  If you are asking is there anything you need that is not open source, I would say probably not.  Our approach is to provide flexible APIs to allow you to use KonaKart as you please.   If there are things that the APIs do not provide we can be responsive to adding these.  There are custom fields on the major objects to allow you plenty of freedom and flexibility when customising KonaKart through the APIs.  We will ensure backwards compatibility in the APIs and encourage people to program their systems against these to allow them to take full advantage of enhancements and bug fixes in future releases with minimal effort to upgrade.

3) Yes the source code is available to purchase although there are conditions over what it can be used for - eg. it cannot be used to produce a product for use or sale outside the purchasing company, but it can be purchased for customisation and use within the purchasing company.  Please contact us by email (enquiries @ konakart.com) for a more detailed discussion on this and let us know about your intended use of KonaKart.

Regards,
John

Hi Sphericus,

There's no reason why you can't load the database directly if you know your way around the schema.

Since we will maintain backwards compatibility with the APIs a more future-proof solution would be to use the APIs - in case the tables change etc.. 

Having said that, in future we will have a friendly mass import tool so if your direct SQL loading fails for some reason in the future due to future KonaKart database changes, you should be able to convert it to use the tool without much trouble.

A good example of "safe" data loading via SQL is the Konakart-Home/database/MySQL-4.1/konakart_demo.sql file which is used to prime the database ready for use.   If you copy the way products and manufacturers are installed in that file, you'll be on safe ground...

Good luck,
John

Hi Oscar,

I don't think v 4.1 was ever specifically recommended, only MySQL itself, but I admit that seeing "MySQL-4.1" in the installation notes could have been misleading... This was ok for previous releases (prior to the introduction of the KK_IF function for portability across all the databases) but not no longer and we will correct that in the kits and the documentation soon.

Good news that you can upgrade your MySQL anyway.  That will save a lot of problems.

Good luck and please let us know how you get on,
John

Hi,

Just to add another possibility...  when our mass import tool is available it will almost certainly use our Admin APIs.

Since these APIs are available today (via plain java objects or SOAP), you might consider processing your data yourself?   This may not be very appealing if you're not a programmer, but there are a number of examples of using the APIs in the FAQs section of the website if you wish to consider this route.  eg. http://www.konakart.com/apiexamplesfaq.php

{We could also provide a bespoke import utility for your data for a modest charge - if you're interested, please contact us by email at enquiries @ konakart . com.}

Regards,
John

Hi Oscar,

Thanks for the post.

I'm afraid that when we added KK_IF for the support for the 5 leading databases (Oracle, DB2, MS SQL Server, MySQL and PostgreSQL) we inrtoduced this syntax that requires MySQL 5 or later.  Can you upgrade to mySQL 5 (or use PostgreSQL, or one of the others)?

The directory naming (database/MySQL-4.1) is due to historical reasons and rather misleading so we'll fix that in the next release.

Rgeards,
John

Hi tsoples,

> Hi, have you ever considered on putting multiple images on a product by using the custom fields of the product table? In some cases it is very useful to have more then one images of the product.

Yes, using the custom fields in this way would be an excellent way to implement multiple images for each product.

> Furthermore, is it possible to use some different admin gui e.g from the oscommerce it self.

Well, if I understand your question correctly, since we are database compatible with oscommerce it would be possible but you must note that we have added extra functionality to KonaKart that does not appear in oscommerce so you should consider our database a super-set of theirs.   In any event, I'm puzzled why you would not want to use the KonaKart AJAX-based Administration Application?

John