From: Honza M. <hon...@ec...> - 2009-07-17 00:53:18
|
Hi Adam, 15. 7. 2009 21:13:06 Adam Sánchez wrote: > Thanks Honza. I think it is very important to the development of > modules in AA. Many have grown CMS today because you can easily write > modules. There are huge directories of modules that the end user will > only download, install and use. You are right, Adam - we need the possibility to download "modules" to AA. I just think that the name "modules" in AA means something different from other CMSs. Modules in most other CMSs are something like "photo-gallery module, petition module, contacts database", ... In AA we are able to create such "modules" just using AA interface and {some_command} constructs. In fact, all webdesiners working with AA are creating "modules". But, because we are using the word "module" in AA for different thing (special datastructures), I would rather call such "module" APPLICATION. What we miss right now is the easy way, how to download, duplicate and exchange such Applications. I already describe this idea when we was trying to do it as part of ActionKit. I'm attaching the description below. Right now, we are moving slowly to meet this goal of exchangeable Apps, but still - some parts still missing. If we want such Applications, we need consistent the AA Core, on top of which we will build the Apps. I mean all the {constructs}, fields, .... So, I would prefer to have all the base functionality integrated in the consistent AA core. That means to encourage developers to submit the changes to AA SVN in order "Apps" developers could count with it. Why not integrate your "Search" functionality directly to the AA core? This of course also mean, that there is still the need for well documented API on adding {construct}, ... What do you think? Honza ---- follows the description of "Apps" idea --- Subject: Re: [Ict-toolsets] discussion summary Date: 2005-09-01 From: Honza Malik <hon...@ec...> To: ict...@gn... [...] *The AA vision of AK* We use SHARED DATABASE in AA, which serve to more than one site/client. It is good for some tasks and also it has its limits, but it is by all means difference from Drupal and similar systems. If you think about it, it looks like the shared database could be extremely useful for Akit. Let's take the shared database idea and extend it to its borders. As Marek said: "Complicated things should be doable, and simple things should be simple. AA only fulfils the first part of the sentence". Right, we are able to do most of things in AA, but we all creating the applications from sketch. We already have petitions, we have press releases archive, we have calendar, news, action letters, photo-galleries, banner exchange system, postcards sending, file archive, alerts, contact management, user database, links ..., but we are not able to share it with others. We are not able to create this applications simply. Solution? Let's teach AA to be able to exchange the applications. It could work just like plug-ins in Firefox or jEdit. You will just click on "Application Manager" icon in AA Admin interface, select Application Repository server and then you select which application you want to install. Then click OK, and say petitions are prepared for use. Of course, you can modify the downloaded petitions, if you want - it is just pre-configured AA slice(s). The application is in fact set of slices, views, designs and possibly also items. We are able to create slice from local template in current AA. Now you will be able to pack your slices with all views to some application and then share it with others - across the servers. You then just specify, that user XY can download your application. Mrs. XY then in his AA opens "Application Manager", she selects your server as Application Repository and she downloads the application. The idea is, that any of AA could be Application Repository. You can download applications from any AA if you have permissions to. In praxis I expect, that there will be one "official" Application Repository (say the AA on actionapps.org), where you will find most of the best applications. Administrators would have permissions also to upload applications to the Repository. Please mention, that you are able to create application without any programing - you just clicking in the AA Admin interface. The same way you are able to install new applications - without any database installing - just click. That's the benefit of shared database. Of course, if you are able to install application form remote server, you are also able to duplicate application within the server. Then you will be able to prepare calendar/shop/petition application and allow users from public webpage to create its own petition (= duplicate the prepared app) - all without our touch. Then we maybe can also setup one AA server for Africa with pre-installed applications, so anyone will be able to come and create campaign site - the people will not need any technician or server administrator. But this is just kind of fantasy. Conclusion - benefits of this approach: - we are able to share applications and know-how - cooperate - we are able to create apps, install apps, duplicate apps or upload apps to Repository without any programming and database installing (take in account, that it is far easier to find web-developer than the programmer - not only in APC organisations) - we make the "simple things simple" in AA - just download the app - we will be able to share also examples, where administrators will see, how the things work in AA (learn by example) - all the apps we can easily extend - it is normal slices - the work on Akit would be spread across more organisations - some of them would program the functionality, some would be creating apps, ... Is it doable? Yes, I think it is not so big problem to make it work. Yes, there are some issues (like naming of views (view ids), solve overall site management, ...), but it is more technical discussion and the problems are solvable. [...] ---------- end of the description of "Apps" idea ---------- Dne St 15. července 2009 21:13:06 Adam Sánchez napsal(a): > Thanks Honza. I think it is very important to the development of > modules in AA. Many have grown CMS today because you can easily write > modules. There are huge directories of modules that the end user will > only download, install and use. > Why the AA can not do the same? We > must provide the documentation and examples for developers. Well, I > answer between the lines below. > > 2009/7/15 Honza Malik <hon...@ec...>: > > Hello guys, > > > > congratulation Adam for your first module! And also thank you for > > starting this discussion. > > > > I have a few notes - about the module itself, the documentation a and > > development process. I will start with documentation. > > > > 1) Documentation > > > > I agree, that the documentation of ActionApps for developpers is far from > > perfect. I can see three reasons for it: > > > > - nobody writes the the textual description of the code or do not > > update it during the time. My fault. > > > > - the Developer's documentation disapeared (was not properly > > transformed) to Wiki documentation, when Marek changed the documentation > > from the one based on AA FAQ to Wiki. The old developer documentation > > could be found on http://www.actionapps.org/faq/index.shtml - see bottom > > of the page. It includes also my text "How to create new module?". Adam, > > did you find and used it? > > I worked with > > /apc-aa/modules/module_TEMPLATE/readme.txt > > > - It is not always necessary or efficient to document the code in > > textual form - form many reasons it is better SOME KIND of documentation > > have documented in directly in the code. The main reason for it is, that > > such documentation is always fresh (and I think the new APIs, based on > > classes are quite well self documented - like the one for the most often > > used classes like AA_Stringexpand). > > It is possible to generate documentation with phpdoc or phpDocumentor? > > > What I would propose is: > > > > - convert the old developer documentation to wiki (as the start for now) > > I can support the documentation of > > http://www.actionapps.org/faq/detail.shtml?x=1687 > > on the construction of modules to the wiki. > > > - write the list of current AA APIs with small description, use cases and > > related files (but not detailed API description, at least now). > > It would be nice! > > > 2) Development process > > > > There are things easy to do (like new {some_command:param:....} > > constructs, item export to CSV, HTML, ..., Optimize functions), which are > > quite well documented in the code and adding new {constructs} or export > > filters is easy. Maybe we just need to list such features and point the > > people to right direction/file (see the proposal above). I think it > > covers most often added functionality. > > > > Of course, there are features, which are harder to implement, they are > > part of the AA core or need some bigger picture about the code of AA. > > you're right, here are some examples: > > I would like to know how to add a view? > I would like to know how to add fields? > I would like to know how to add fields to user profile? > > but even these changes should be included as modules and not direct > changes to the core. > > > I would encourage developers to write an email to apc-aa-coders, what > > they are planning to implement. Mainly if they are planning to implement > > some feature from the second category. Maybe we can give you some hint, > > how we see the best implementation of that functionality. There are many > > benefits from it: > > > > - maybe we can find the easier solution to the problem > > - maybe you get some hints > > - other people can suggest other functionality and extension which you > > could take into account > > - maybe you will find some cosponsor or coworker > > - such code will be easier accepted for inclusion to ActionApps SVN > > > > > > 3) The Search module. > > > > I think it is great example of the module implementation. Yes, it is how > > you would write the module. I have one question - did you Adam consider > > to implement this functionality directly into "AA Finder" page? > > > > https://aa.ecn.cz/aaa/admin/aafinder.php3 > > > > I'm not sure, if the search functionality is the right place for Module. > > I think module is a bit too complex for such thing - it can hold its own > > datastructures, its own User Interface and also mainly - you can assign > > permissios to such module (instances). > > > > As I see, the user in the Search module is able to search whole database > > - all the slices. So it MUST be permitted only to superadmins (just like > > the "AA Finder") page. What do you think? > > Ok, but at this point I have some suggestions. > The AA should have an interface to load the modules more easily > without having to edit files such as core constants.php3 and > sql_update.php3. Should be activated or deactivated at will. > There should be two types of modules, core modules and custom modules. > Not all modules should enter the core because it would make heavy. > > Regards, > > Adam > > > Honza > > > > Dne Po 13. července 2009 Ariel Barbosa napsal(a): > >> Hi, Honza, what do you think about this proposal to prepare a full > >> documentation of the action-apps API? Do you have plans about that? > >> > >> Un saludo, > >> > >> Ariel Barbosa > >> > >> Inscríbase al 12º Taller sobre Tecnologías de Redes > >> Internet para América Latina y el Caribe (WALC 2009) > >> Bogotá, 21 al 25 de Septiembre de 2009 > >> http://www.eslared.org.ve/walc2009 > >> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> ARIEL BARBOSA > >> Coordinador de Proyectos Web > >> Colnodo - Red APC Colombia > >> Diag. 40A (Ant. Av. 39) No. 14-75, Bogotá, Colombia > >> Tel: +571 2324246 > >> Fax: +571 338 0264 > >> http://www.colnodo.apc.org * ar...@co... > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > >> Adam Sánchez escribió: > >> > Hi Julian, > >> > Best writing in English to include Honza. > >> > I think it is better to work in an orderly manner and focus on the > >> > development of modules for the AA. I think the lack of comprehensive > >> > documentation on the subject was one of the reasons for the slow > >> > growth of the community of programmers. If the API of the AA to be > >> > better documented we could certainly go further. In developing this > >> > module I had to get to review all files of the AA to extract the > >> > features you need to understand. It took me a long time! > >> > So, in my humble opinion the biggest challenge is to begin to document > >> > the API of the AA. > >> > The contribution of Alexander should be integrated as a module and not > >> > necessarily the core. > >> > Regards, > >> > Adam > >> > > >> > 2009/7/13 Julian Casasbuenas G. <ju...@co...>: > >> >> Hola Adam, > >> >> > >> >> Copio este mensaje también a Alejandro que ha desarrollado algunas > >> >> mejoras (p.e. control de spam a los formularios y mejoras a > >> >> calendarios de eventos) que me parece clave sean incluidas en el > >> >> código de las AAs directamente. Cómo ven Uds esta posibilidad? Ahora > >> >> tenemos un proceso en Colombia de evaluación de la plataforma y tener > >> >> aportes de > >> >> desarrolladores de la región más visibles a través de sourceforge es > >> >> clave para el futuro de las AAs. Copio a Honza para ver cómo podemos > >> >> viabilizar estas actualizaciones directamente. > >> >> > >> >> Estamos en contacto, > >> >> > >> >> Julián > >> >> > >> >> Adam Sánchez escribió: > >> >>> Hola a todos > >> >>> > >> >>> Les comparto un modulo que construi para las AA 2.50. Este modulo > >> >>> sirve para hacer busquedas internas. > >> >>> Las instrucciones de instalacion estan dentro del archivo LEAME..txt > >> >>> Fundamentalmente es un demo que ayuda a entender como se pueden > >> >>> añadir modulos a las AA, un tema poco documentado hasta ahora para > >> >>> los programadores php > >> >>> El modulo les debe salir como esta imagen > >> >>> http://yfrog.com/0wsearchezcp > >> >>> > >> >>> Saludos, > >> >>> Adam. > >> >>> > >> >>> -------------------------------------------------------------------- > >> >>>--- - > >> >>> > >> >>> -------------------------------------------------------------------- > >> >>>--- ------- Enter the BlackBerry Developer Challenge > >> >>> This is your chance to win up to $100,000 in prizes! For a limited > >> >>> time, vendors submitting new applications to BlackBerry App > >> >>> World(TM) will have the opportunity to enter the BlackBerry > >> >>> Developer Challenge. See full prize details at: > >> >>> http://p.sf.net/sfu/Challenge > >> >>> -------------------------------------------------------------------- > >> >>>--- - > >> >>> > >> >>> _______________________________________________ > >> >>> ¿Recibiste respuestas a tus preguntas sobre ActionApps? Si es > >> >>> así, ayuda por favor a la comunidad de ActionApps publicando > >> >>> las respuestas a tus preguntas a la documentación de > >> >>> ActionApps. Ve la sección *cómo contribuir* en > >> >>> http://www.actionapps.org/es/C%C3%B3mo_contribuir > >> >>> _______________________________________________ > >> >>> Apc-aa-espanol mailing list > >> >>> Apc...@li... > >> >>> https://lists.sourceforge.net/lists/listinfo/apc-aa-espanol > >> >> > >> >> -- > >> >> > >> >> Julian Casasbuenas G. > >> >> Director Colnodo > >> >> Diagonal 40A (Antigua Av. 39) No. 14-75, Bogota, Colombia > >> >> Tel: 57-1-2324246, Cel. 57-315-3339099 Fax: 57-1-3380264 > >> >> www.colnodo.apc.org - Uso Estratégico de Internet para el Desarrollo > >> >> Miembro de la Asociacion para el Progreso de las Comunicaciones -APC- > >> >> www.apc.org |