Difference between revisions of "Easy dictionary maintenance"

From Apertium
Jump to navigation Jump to search
Line 1: Line 1:
  +
{{TOCD}}
−
==Easy Dictionary Maintenance - Student Reports==
 
  +
= Introduction =
 
This space will report developments in the project.
  
This space will report developments in the project.
 
It is also a space to post comments and suggestions.
  
It is also a space to post comments and suggestions.
   
−
==Original Ideias==
 +
;Original Ideias
−
http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code
 +
: http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code
  ⚫
: http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code/Easy_dictionary_maintenance
   
  ⚫
;Original GSOC2010 Application
⚫
http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code/Easy_dictionary_maintenance
  
  ⚫
: http://wiki.apertium.org/wiki/User:Alessiojr/Easy_dictionary_-_Application-GSOC2010
   
  +
;Studant Information
⚫
==Original AlessioJr GSOC2010 Application==
  
  ⚫
: '''Student:''' Alessio Miranda Junior<br />
⚫
http://wiki.apertium.org/wiki/User:Alessiojr/Easy_dictionary_-_Application-GSOC2010
  
  ⚫
: '''E-mail:''' alessio@inf.ufpr.br or alessio@alessiojr.com<br />
  ⚫
: '''Msn:''' msn@juninho.com.br<br />
  ⚫
: '''IRC:''' AlessioJr<br />
  ⚫
: '''GTalk:''' alessiojunin@gmail.com
   
  +
=Description=
−
==Title: ''Easy dictionary maintenance''==
  
  ⚫
==Abstract:==
⚫
'''Student:''' Alessio Miranda Junior<br />
  
⚫
'''E-mail:''' alessio@inf.ufpr.br or alessio@alessiojr.com<br />
  
⚫
'''Msn:''' msn@juninho.com.br<br />
 
⚫
'''IRC:''' AlessioJr<br />
  
⚫
'''GTalk:''' alessiojunin@gmail.com
  
   
  ⚫
;The idea is to develop a GUI tool to manage Apertium Monolingual and Bilingual XML files with the follow objectives:
⚫
'''Abstract:'''
  
  ⚫
:* Create a alternative form to edit dix files with GUI resources.
⚫
The idea is to develop a GUI tool to manage Apertium Monolingual and Bilingual XML files with the follow objectives:
  
  ⚫
:* Develop, initially, monolingual dictionaries but keeping the particular format of each file.
⚫
• Create a alternative form to edit dix files with GUI resources.
  
  ⚫
:* Minimize the direct manipulation of XML files, providing features that reduce this need.
⚫
• Develop, initially, monolingual dictionaries but keeping the particular format of each file.
  
  ⚫
:* Making use of DixTools to keep code reuse.
⚫
• Minimize the direct manipulation of XML files, providing features that reduce this need.
  
⚫
• Making use of DixTools to keep code reuse.
  
   
−
'''Why?'''
 +
==Why?==
−
The number of language pairs in development for Apertium is increasing, and so is the complexity of these pairs.
 +
The number of language pairs in development for Apertium is increasing, and so is the complexity of these pairs.
−
This increased complexity has made the job getting more complicated, thus the need for tools for the task is evident.
+
This increased complexity has made the job getting more complicated, thus the need for tools for the task is evident.
−
The proposed want to make this management easier and probably will increase the probability of development for new
 +
The proposed want to make this management easier and probably will increase the probability of development for new
−
language pairs. With better tools, more people will be able to develop language pairs.
 +
language pairs. With better tools, more people will be able to develop language pairs.
   
−
'''How can use?'''
 +
==How can use?==
−
I believe that all Apertium society will have direct or indirect benefit. Directly, the developers
 +
I believe that all Apertium society will have direct or indirect benefit. Directly, the developers
−
of language-pairs will have their task facilitated. With a good tool to help with the work, to create
 +
of language-pairs will have their task facilitated. With a good tool to help with the work, to create
−
or maintain a language will become easier, and probably it will take less time to get better results.
 +
or maintain a language will become easier, and probably it will take less time to get better results.
−
Indirectly, the users will have benefits with this better and robust result.
 +
Indirectly, the users will have benefits with this better and robust result.
   
−
'''What its the plan?'''
 +
==What its the plan?==
  +
* We're planing to create a GUI interface with features that facilitate common tasks of a user who wishes to manipulate a existing language pair or dictionary. These tasks will also be of great value to users, who have an intuitive tool to start new language pairs.
   
  ⚫
* DixTools, tool developed for the apertium, currently already solves half the problem, especially the fact that a load XML into memory and do the reverse, it returns the XML in a suitable format.
−
We're planing to create a GUI interface with features that facilitate common tasks of a user who wishes
  
−
to manipulate a existing language pair or dictionary. These tasks will also be of great value to new
  
−
users, who have an intuitive tool to start new language pairs.
  
   
  +
* We believe that the main challenge of this task is to find a way to expand DixTools by adapting the existing classes as a persistence layer connected to a framework for GUI applications, supporting an integration of elements, providing tools to search, filter, integration and change.
⚫
DixTools, tool developed for the apertium, currently already solves half the problem, especially the
  
−
fact that a load XML into memory and do the reverse, it returns the XML in a suitable format.
  
   
  ⚫
* The application is developed for monolingual dictionaries manipulation, but its architecture will have to provide support for future extensions (Web and Collaborative) and bilingual dictionary.
−
We believe that the main challenge of this task is to find a way to expand DixTools by adapting the
  
−
existing classes as a persistence layer connected to a framework for GUI applications, supporting an
  
−
integration of elements, providing tools to search, filter, integration and change.
  
   
  +
=Development Report=
⚫
The application is developed for monolingual dictionaries manipulation, but its architecture will have
  
−
to provide support for future extensions (Web and Collaborative) and bilingual dictionary.
  
   
−
'''What we will try to use?'''
 +
==What we are using?==
  ⚫
===Development Paradigm:===
  +
[[Image:ModelViewControllerDiagram.svg.png‎|frame|Model-View-Controller concept. The solid line represents a direct association, the dashed an indirect association via an observer (for example).]]
  +
  +
;'''Model–View–Controller (MVC)'''
  +
: is a '''software architecture''', currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (GUI), permitting independent development, testing and maintenance of each.
  +
  +
: '''The model layer''' is used to manage information and notify observers when that information changes. The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can be refreshed. Many applications use a persistent storage mechanism such as a database to store data, a model which knows how to persist itself.
  +
  +
:'''The view layer''' renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
  +
  +
: '''The controller layer''' receives input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input.
  +
  +
: '''An MVC application''' may be a collection of model/view/controller triplets, each responsible for a different UI element.
  +
  ⚫
==='''Program Language:''' Java<br />===
  ⚫
==='''Persistence:''' XML (Apertium XML Files), JavaDB or Postgres<br />===
  ⚫
==='''Framworks:''' Dixtools, JPA, Netbeans Platform<br />===
  +
  +
'''Why NetBeans Platform?'''
  +
  +
About NetBeans Platform
  +
  +
The NetBeans Platform is a generic framework for commercial and open source desktop Swing applications. It provides the “plumbing” that you would otherwise need to write yourself, such as the code for managing windows, connecting actions to menu items, and updating applications at runtime. The NetBeans Platform provides all of these out of the box on top of a reliable, flexible, and well-tested modular architecture. In this refcard, you are introduced to the key concerns of the NetBeans Platform, so that you can save years of work when developing robust and extensible applications.
  +
  +
[http://platform.netbeans.org/tutorials/nbm-quick-start.html Netbeans Platform Reference]
  +
  +
The key benefit of the NetBeans Platform is its modular architecture. Secondary benefits are the NetBeans Platform's reliance on the Swing UI toolkit, which is the official toolkit for creating user interfaces in Java, in combination with the NetBeans IDE's award winning "Matisse" GUI Builder.
  +
  +
* OpenSource
  +
* OpenSource
  +
* Designed with the idea that Software should be re-usable.
  +
* Generic Desktop framework
  +
* NetBeans platform provides the basic underpinning
  +
* NetBeans platform is a set of frameworks built into a single integrated software
  +
** Collection of libraries
  +
** Swing Extensions
  +
** NetBeans platform toolkit
  +
* Modules, modules and some more modules.
  +
* Modular architecture gives extensibility and helps to maintain the compatibility
   
⚫
'''Development Paradigm:''' MVC Paradigm<br />
  
⚫
'''Program Language:''' Java/SWING<br />
  
⚫
'''Persistence:''' XML (Apertium XML Files)<br />
  
⚫
'''Framworks:''' Dixtools, JPA, Swing Application Framework<br />
  
   
 
'''Timeline/Stages/Milestones?'''
  
'''Timeline/Stages/Milestones?'''

Revision as of 21:34, 26 June 2010

Introduction

This space will report developments in the project. It is also a space to post comments and suggestions.

Original Ideias
http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code
http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code/Easy_dictionary_maintenance
Original GSOC2010 Application
http://wiki.apertium.org/wiki/User:Alessiojr/Easy_dictionary_-_Application-GSOC2010
Studant Information
Student: Alessio Miranda Junior
E-mail: alessio@inf.ufpr.br or alessio@alessiojr.com
Msn: msn@juninho.com.br
IRC: AlessioJr
GTalk: alessiojunin@gmail.com

Description

Abstract:

The idea is to develop a GUI tool to manage Apertium Monolingual and Bilingual XML files with the follow objectives
  • Create a alternative form to edit dix files with GUI resources.
  • Develop, initially, monolingual dictionaries but keeping the particular format of each file.
  • Minimize the direct manipulation of XML files, providing features that reduce this need.
  • Making use of DixTools to keep code reuse.

Why?

The number of language pairs in development for Apertium is increasing, and so is the complexity of these pairs. This increased complexity has made the job getting more complicated, thus the need for tools for the task is evident. The proposed want to make this management easier and probably will increase the probability of development for new language pairs. With better tools, more people will be able to develop language pairs.

How can use?

I believe that all Apertium society will have direct or indirect benefit. Directly, the developers of language-pairs will have their task facilitated. With a good tool to help with the work, to create or maintain a language will become easier, and probably it will take less time to get better results. Indirectly, the users will have benefits with this better and robust result.

What its the plan?

  • We're planing to create a GUI interface with features that facilitate common tasks of a user who wishes to manipulate a existing language pair or dictionary. These tasks will also be of great value to users, who have an intuitive tool to start new language pairs.
  • DixTools, tool developed for the apertium, currently already solves half the problem, especially the fact that a load XML into memory and do the reverse, it returns the XML in a suitable format.
  • We believe that the main challenge of this task is to find a way to expand DixTools by adapting the existing classes as a persistence layer connected to a framework for GUI applications, supporting an integration of elements, providing tools to search, filter, integration and change.
  • The application is developed for monolingual dictionaries manipulation, but its architecture will have to provide support for future extensions (Web and Collaborative) and bilingual dictionary.

Development Report

What we are using?

Development Paradigm:

Model-View-Controller concept. The solid line represents a direct association, the dashed an indirect association via an observer (for example).
Model–View–Controller (MVC)
is a software architecture, currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (GUI), permitting independent development, testing and maintenance of each.
The model layer is used to manage information and notify observers when that information changes. The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can be refreshed. Many applications use a persistent storage mechanism such as a database to store data, a model which knows how to persist itself.
The view layer renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it.
The controller layer receives input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input.
An MVC application may be a collection of model/view/controller triplets, each responsible for a different UI element.

Program Language: Java

Persistence: XML (Apertium XML Files), JavaDB or Postgres

Framworks: Dixtools, JPA, Netbeans Platform

Why NetBeans Platform?

About NetBeans Platform

The NetBeans Platform is a generic framework for commercial and open source desktop Swing applications. It provides the “plumbing” that you would otherwise need to write yourself, such as the code for managing windows, connecting actions to menu items, and updating applications at runtime. The NetBeans Platform provides all of these out of the box on top of a reliable, flexible, and well-tested modular architecture. In this refcard, you are introduced to the key concerns of the NetBeans Platform, so that you can save years of work when developing robust and extensible applications.

Netbeans Platform Reference

The key benefit of the NetBeans Platform is its modular architecture. Secondary benefits are the NetBeans Platform's reliance on the Swing UI toolkit, which is the official toolkit for creating user interfaces in Java, in combination with the NetBeans IDE's award winning "Matisse" GUI Builder.

  • OpenSource
  • OpenSource
  • Designed with the idea that Software should be re-usable.
  • Generic Desktop framework
  • NetBeans platform provides the basic underpinning
  • NetBeans platform is a set of frameworks built into a single integrated software
    • Collection of libraries
    • Swing Extensions
    • NetBeans platform toolkit
  • Modules, modules and some more modules.
  • Modular architecture gives extensibility and helps to maintain the compatibility


Timeline/Stages/Milestones?

Week Stage Description
1, 2 Analysis of technology in handling memory To investigate and select an effective way to view and manipulate the XML files of Apertium in memory using Java.
Analysis of the best technologie that complement the functionality of DixTools during manipulation of XML.
Maybe a database integration, trying to use VTD-XML or extend dixTools Classes.
Testing and choosing the best alternative.
2, 3 Development of first prototype Development of an interface that tries to use a core of features like Load, Save, list , search and Filter elements.
Prototype Milestone 1 First version for community analysis. Provides the basic architecture, the interface model, and basic handling.
5, 6 Simple Structures Implementation of Symbols, Alphabet and statistic features.
Need Drawings experiments to create interface to users.
7 Paradigms First implementation of features with paradigms.
Need Drawings experiments to create interface to users.
8 Lemmas First implementation of features with lemmas.
Need Drawings experiments to create interface to users.
Prototype Milestone 2 Version for testing with huge dictionaries and complete edition test with basic features.
9 Paradigms With feedback of the community, adjusting the interface and implementation, and probably adding new features.
10 Lemmas With feedback of the community, adjusting the interface and implementation, and probably adding new features.
11 Pré-Release Security time to improve integration functionalities
Prototype Release Candidate
12 Makeup Fix remain bugs, final adjustments and documentation in Wiki
Final Release
Retrieved from "https://wiki.apertium.org/w/index.php?title=Easy_dictionary_maintenance&oldid=20136"